Blocking Credential Stuffing Attacks

We have all heard of account takeover attempts by hackers to gain access to online accounts by guessing user accounts and passwords. Credential stuffing is an account takeover method that leverages a weak point of many users—their re-using of passwords. Here the perpetrator obtains a list of usernames and passwords leaked from one service, say yahoo.com, and runs them against other well-known services—gmail.com and linkedin.com, for example.

The scale of recent leaked credentials lists, often reaching hundreds of thousands or even millions of records in a single hack, lead attackers to develop and use new methodologies, moving forward from the old and basic brute-force attack.

More recently, botnets were introduced into credential stuffing attacks to allow for distributing load between different nodes, but also to overcome simple defense mechanisms by spreading the attack between hundreds or thousands of sources. Tools to automate client interaction were then developed, so that they can be deployed on the botnet’s zombie devices. As a result, cybercrime communities have emerged, recommending tactics and selling automated client configuration files dedicated to particular targets.

We recently saw this threat in the wild when detecting and mitigating credential stuffing attacks attempted on Incapsula customers.

Anatomy of an Attack

A typical attack unfolds in these stages:

1. The attacker steals credentials from a site or in some cases acquires spilled credentials from a site breach. Since many users have the same credentials for multiple accounts, the stolen credentials can provide access to other accounts.
2. The attacker uses a botnet with tools which simplify the process of checking masses of credentials against multiple accounts and defeat simple detection and mitigation mechanisms.
3. When there is a successful login, the attacker can take over the accounts to use the personal information, such as credit card numbers. The attacker might also use the account for other malicious purposes, such as sending spam from an email account.

The success rate will be low, on average of 1 percent or less. However, with a botnet and the tool that can examine large numbers of accounts, the result can be thousands of successful account breaches.

A Media Service Under Attack

The Incapsula security group was recently called to aid a media service targeted by such attacks. With an intense research effort and valuable cooperation by the customer, we were able to pinpoint and mitigate the attack.

Our investigation started with identifying the presence of a known tool used for automating access to the authentication process on the target domain. The tool is Sentry MBA, an HTTP bot which allows automated interaction with webpages. The tool is highly configurable and can mitigate security controls, such as rate limiting or simple CAPTCHAs. The configuration file required to navigate the unique characteristics of the target site can be complex to create. However, since it requires knowledge of the site’s controls, ready-made configuration files for many sites can be purchased online.

By investigating the source IPs used by this botnet, we quickly found a common pattern: Many of them were associated with a particular brand of home routers, that had been publicly reported to have serious vulnerabilities just a month before.

These findings allowed us to employ the advanced Incapsula classification engine to target the attacking bots. Using new classification techniques, we identified a unique TLS fingerprint that was associated with the router platform.  We were then able to target and block the specific attack without impacting legitimate users.

The TLS fingerprint is based on the Hello packet the client sends at start of the TLS session between client and server. Since this packet is not encrypted and is static from session to session for each client, the client is uniquely identified based on data in the packet.

×

Nov 26 Upcoming Webinar

The True Cost of API Insecurity and Bot Attacks in 2024

Register Now

Protecting the Site with Incapsula

Incapsula has several tools to defend against the attacks and we implemented them, where required, at the media service. The rules shown below are IncapRules our customers use to configure security, delivery, and access control rules. They can be manually coded or generated using a dedicated GUI.

• Rate limiting – Since the credential attacks are just trying to ascertain whether a login succeeds, the attack is targeted to the login page. An Incapsula rule can be defined that will limit the rate of access to the page per IP or per session. When the rate is exceeded, access is blocked with a response that is defined in the rule.

Check with Incapsula support to determine the best rule to apply on your system. This sample rule filters an IP that made more than 15 POST requests in one minute to a URL that has the word login:

Check with Incapsula support to determine the best rule to apply on your system.

To cover cases where the login page URL does not have the word login, you can then add the following rule to filter common parameter names on the login page, such as username, user or password:

For each rule an action is defined, such as to block the request or to require a CAPTCHA.

• Client classification – Incapsula can stop bad bots by its classification process that will automatically block access from a client which it has classified as a bad bot. You can define a specific Incapsula classification rule, such as the following, for a web site that is expecting only browsers and search bots to visit the site.

• Flow control – The request and response from a legitimate client follows a defined expected user flow, whereas an attacker might not follow that flow. For example, the attacker might send the POST request with the credentials before visiting the login page. This Incapsula rule can be defined to detect that deviation from the expected pattern, and block that access.

Site Protection Recommendations

Start by protecting and monitoring your site to harden accounts against the possibility of access by an attacker. These are some of the actions that we strongly recommend.

• Reduce your attack surface – When you develop the system, reduce the number of authentication points where a user can access the system and get data out of it. For example, use a single authentication endpoint for similar business flows. Try to avoid maintaining legacy and new authentication endpoints or different endpoints for different subdomains serving the same user. Follow the OWASP cheat sheet to map and assess the attack surface.

As an example of an additional login attack surface, there was a recent attack on the Forgot Password interface of a commerce site. We believe that the perpetrator in this case was using breached email account credentials to get accounts connected to that email address. By initiating multiple requests to the site’s Forgot Password page, in an attempt to access the email to reset the password, an attacker could take control of the commerce account. We created a rule that detected and blocked the attack. See recommendations on how to harden your site against such an attack.

• Login enforcement – Use this to identify anomalies such as multiple failed login attempts from the same IP or user, or a sharp increase in login attempts in a short time. Encourage the use of two-factor authentication to the site.
• Log auditing – Log access to the system and monitor for unexpected activity. Use a standard log format that can be input to available log monitoring tools.
• Information exposure – Do not disclose more information than required in messages or log entries. For example, on a failed login attempt do not disclose which portion of the login is incorrect.

Summary

With the large scale of credential stuffing attacks, enabled by botnets and automated tools, be sure to protect your site with the Incapsula tools and suggestions we’ve described.