Google has more than 20 years of experience protecting its core service from Distributed Denial of Service (DDoS) attacks and from the most advanced web application attacks. With Cloud Armor, we have enabled our customers to benefit from our extensive experience of protecting our globally distributed products such as Google Search, Gmail, and YouTube.
In our research, we have noticed that new and more sophisticated techniques are increasingly able to bypass and override most of the commercial anti-DDoS systems and Web Application Firewalls (WAF). Credential stuffing is one of these techniques.
From our partners:
Credential stuffing is one of the hardest to detect attacks because it’s more like the tortoise and less like the hare. In a slow but steady manner, the attacker exploits a list of usernames and passwords, often first available illicitly after a data breach, and uses automated techniques to force these compromised credentials to give them unauthorized access to a web service.
While password reuse habits and the ever-growing number of stolen credential collections are making it easier for organizations uncover and report this type of “brute force” technique to law enforcement and technology providers, today’s credential stuffing attacks often leverage bots or compromised IoT devices to reach a level of scale and automation that earns the attackers far better results than the type of brute-force attacks deployed even a few years ago.
Nevertheless, a defense-in-depth approach to cloud security can help stuff even advanced credential stuffing attacks. One technique is to secure user accounts with multi-factor authentication. In case of breach, the extra layer of protection that MFA creates can protect a password exposure from resulting in a successful malicious login. Unfortunately, we know that imposing such a requirement isn’t always appropriate or possible. In case of MFA failure or implementation challenges, additional controls to protect the websites that expose login forms against credential stuffing attacks can be deployed.
We outline below how Google Cloud can help reduce the likelihood of a successful credential stuffing attack by building a layered security strategy that leverages native Google technologies such as Google Cloud Armor and reCAPTCHA Enterprise.
Google Cloud Armor overview
Google Cloud Armor can help customers who use Google Cloud or on-premises deployments to mitigate and address multiple threats, including DDoS attacks and application attacks like cross-site scripting (XSS) and SQL injection (SQLi).
Google Cloud Armor’s DDoS protection is always-on inline, scaling to the capacity of Google’s global network. It is able to instantly detect and mitigate network attacks in order to allow only well-formed requests through the load balancing proxies.
This product provides not only anti-DDoS capabilities, but allows with a set of preconfigured rules to protect web applications and services from common attacks from the internet and help mitigate the OWASP Top 10 vulnerabilities.
One of the most interesting features of Cloud Armor, especially for the credential stuffing attack protection, is the possibility to apply rate-based rules to help customers to protect the applications from a large volume of requests that flood instances and block access for legitimate users.
Google Cloud Armor has two types of rate-based rules:
- Throttle: You can enforce a maximum request limit per client or across all clients by throttling individual clients to a user-configured threshold. This rule enforces the threshold to limit traffic from each client that satisfies the match conditions in the rule. The threshold is configured as a specified number of requests in a specified time interval.
- Rate-based ban: You can rate limit requests that match a rule on a per-client basis and then temporarily ban those clients for a specified time if they exceed a user-configured threshold.
Google Cloud Armor security policies enable you to allow or deny access to your external HTTP(S) load balancer at the Google Cloud edge, as close as possible to the source of incoming traffic. This prevents unwelcome traffic from consuming resources or entering your Virtual Private Cloud (VPC) networks.
The following diagram illustrates the location of the external HTTP(S) load balancers, the Google network, and Google data centers.
A defense-in-depth approach to credential stuffing protection
It is important to design security controls in a layered approach without relying only on a single defense mechanism. This strategy is known as defense-in-depth and if correctly applied, allows to achieve reasonable degrees of security.
In the following sections we will discuss the layers that can be implemented using Google Cloud Armor to protect against credential stuffing attacks.
Layer 1 – Geo-blocking and IP-blocking
Non-sophisticated credential stuffing attacks are likely to use a limited number of IP addresses, often traceable to nation states. It is possible to start the defense-in-depth approach trying to identify the regions where the website that has to be protected should be available. For example, if the web is expected to be used only by U.S. users it is possible to set a deny rule using an expression like the following:
origin.region_code != 'US'
Likewise, it is possible to apply a deny rule to block traffic that is originated by a list of regions, where the application shouldn’t be available. For example, if we want to block traffic from the United States and Italy, it is possible using the following expression:
origin.region_code == 'US' || origin.region_code == 'IT'
Additionally, it is possible to react to ongoing attacks creating a denylist for IP addresses or CIDRs, with a limit of 10 IP addresses, or ranges, per rule. An example would be:
inIPRange(origin.ip, '9.9.9.0/24')
While Geo-blocking and IP-blocking are good mechanisms to stop trivial attacks or to limit an attack, there is more that can be done to block attackers. Most of the sophisticated credential stuffing attack tools can be configured with proxies or to use compromised IoT devices to bypass IP-based controls.
Layer 2 – HTTP headers
Another way to improve defensive configurations is to add additional checks over the HTTP headers of the requests coming to the application. One of the main examples is the user-agent. The user-agent is a request header that helps the application to identify which operating system and which browser are being used usually to improve the user experience. The attackers do not frequently care about helping the application to better serve the user; in an attack scenario the HTTP headers are either completely missing or malformed. Below you can find an example rule to check the user-agent presence and correctness.
has(request.headers['user-agent']) && request.headers['user-agent'].matches('Chrome')
HTTP headers can be helpful to further reduce the attack surface, but they also have their limits. They are still controlled on the client side, which means an attacker can spoof them. To achieve maximum security results from configuring HTTP headers, it is necessary to more fully understand the HTTP headers that the application expects to encounter and to properly configure the Google Cloud Armor rule.
Layer 3 – Rate Limiting
As we’ve noted, the nature of credential stuffing attacks makes them difficult to identify. They are also often associated with password spraying techniques that target not only breached username and password pairs, but also widely-used, known weak passwords (such as “123456.”). Rate limiting protection mechanisms work well in these scenarios to add an additional defensive layer.
When we deal with rate limiting, it’s important to identify the standard rate that a legitimate user would have, and to understand the threshold of requests that would be blocked if exceeded. Finding the right balance between security and user experience is often challenging. To help fine-tune rate limiting so that legitimate users are not blocked, Google Cloud Armor’s Preview mode allows security teams to test rate limiting without any real enforcement. In order to minimize user impact, we strongly recommended proceeding in this way followed by an analysis of the test results.
Once the preliminary analyses have been completed, it is possible to use Google Cloud Armor to implement rate limiting rules. An example of a rule that applies a ban (which the user sees as a 404 error) of 5 minutes after 50 connections in less than 1 minute from the same IP address would be:
gcloud compute security-policies rules create 100 \--security-policy=sec-policy \--action=rate-based-ban \--rate-limit-threshold-count=50 \--rate-limit-threshold-interval-sec=60 \--ban-duration-sec=300 \--conform-action=allow \--exceed-action=deny-404 \--enforce-on-key=IP
When it comes to rate limiting the client identification is fundamental. The IP address could be the first option, but there are cases where it wouldn’t be enough. For example, many Internet service providers use natting techniques to reduce the public IP addresses space needed. Of course, the probability of an IP clash is low, but it is something that should be taken into account when designing the rate limiting thresholds and strategy. Cloud Armor can identify individual clients in many ways such as using IP addresses, HTTP headers, HTTP cookies and XFF-IPs.
For example, it is common for mobile apps to be designed to use custom headers with unique values to better identify each client in a reliable way. In this case, it would be appropriate to enforce the client identification based on this custom header rather than the IP address. Below is an example rule based on the custom header ‘client-random-id’.
gcloud compute security-policies rules create 100 \--security-policy=sec-policy \--action=rate-based-ban \--rate-limit-threshold-count=50 \--rate-limit-threshold-interval-sec=60 \--ban-duration-sec=300 \--conform-action=allow \--exceed-action=deny-404 \--enforce-on-key=HTTP-HEADER \--enforce-on-key-name='client-random-id'
Layer 4 – reCAPTCHA Enterprise and Google Cloud Armor integration
An additional level of protection, combined with the previously mentioned techniques, would be the native integration of Google Cloud Armor with reCAPTCHA Enterprise technology.
The integration could be made using a rate limiting rule similar to the one described above. Instead of returning a 404 error, it can be configured to redirect the connection to a reCAPTCHA Enterprise challenge at the WAF layer. At this stage the following events take place:
- Cloud Armor verifies the rate limiting criteria and if exceeded would redirect the connection to reCAPTCHA Enterprise.
- reCAPTCHA Enterprise performs an assessment of the client interaction and if necessary challenges the user with a CAPTCHA.
- If the user fails the assessment an error message is returned. If the assessment is passed reCAPTCHA issues a temporary exemption cookie.
- Cloud Armor verifies the exemption cookie validity and grants access to the site.
The following diagram shows the event sequence:
Conclusions
Credential stuffing is a non-trivial attack and should be mitigated first with multi-factor authentication mechanisms and user education. Some technical measures can be implemented to apply a defense-in-depth model. Google Cloud Armor should be used to implement security mechanisms such as:
- Geo-Blocking
- HTTP Header verification
- Rate Limiting
And, as an additional security layer:
- A combination of reCAPTCHA Enterprise and Google Cloud Armor
These controls can achieve a reasonable degree of protection against not only credential stuffing attacks, but also brute-force attacks and general protection against bot-driven attacks.
By: Davide Annovazzi (Google Cloud Security & Compliance)
Source: Google Cloud Blog
For enquiries, product placements, sponsorships, and collaborations, connect with us at [email protected]. We'd love to hear from you!
Our humans need coffee too! Your support is highly appreciated, thank you!
