Here at Reclaim.ai, we process Google Calendar data for our 200,000 global users and treat that responsibility very seriously. Security is goal-zero, and we appreciate the trust you place in our platform and services. In light of the recent discovery and activity of the HTTP/2 ‘Rapid Reset Attack’ (CVE-2023-44487), we felt it would be worth a short blog post to clarify the impact to Reclaim.ai (none), and the steps we’ve taken to proactively address any future potential impact.

TL;DR - Reclaim.ai is not impacted by this vulnerability

Blog posts about technical security may not be applicable to everyone, but the outcomes of security incidents are, so we’ll summarize the key things to know:

1. Reclaim Customer Data from this incident is NOT at risk.
2. This Zero-Day attack has NOT been specifically directed at Reclaim.ai, thus far.
3. This type of attack is a distributed denial-of-service (DDoS) attack and NOT a hack, ransomware or similar attack where customer or confidential data is compromised.
4. We have validated that appropriate technical countermeasures with our sub-processors have been implemented proactively (more detail below).

Let’s walk through the details of the attack itself, and the proactive steps we’ve taken at Reclaim.ai to mitigate any future impact.

Overview of the HTTP/2 Rapid Reset Attack

One of the implementations of HTTP/2 is to allow multiple connections to be simultaneously multiplexed over a single HTTP connection. The HTTP/2 Rapid Reset Attack exploits this functionality by sending multiple HTTP/2 connections with rapid (hence the name of the attack) requests and resets in succession. 

For each request, the web server will process and often log each request, including the reset request, so a malicious client can easily overload a web server by sending bogus requests. This results in pain and hurting for the web server – which ultimately compromises the performance and availability of the service it is supporting.

What makes this “vulnerability” rather interesting is that it’s not a typical bug or defect in the HTTP/2 protocol, rather it’s exploiting the way the protocol is designed. What this means it that:

• Any web server that supports HTTP/2 is vulnerable.
• The requests an attacker makes are legal, legitimate requests – they just make them in a way that defeats flood prevention with little effort.
• The ease of creating attacks with this vector has resulted in some of the largest DDoS attacks in history, as observed and reported by Cloudflare and the biggest attack reported by Google.

Mitigation actions taken by Reclaim

Basically, the best way to mitigate current and future impact from this attack is to leverage defensive countermeasure capabilities from infrastructure providers, or as we call them – sub-processors.

We are very picky about which sub-processors we use, with security and privacy technical measures being the most important criteria. In some ways, this incident validates our vendor selection process as each of our sub-processors 

• Were transparent about impact and their capabilities.
• Exposed those capabilities to their customers to reduce the exposure of the attack.
• Either proactively posted or answered any clarifying questions we had about this attack.

All of our sub-processors are listed on our Security page, but we will outline the applicable ones and the relevant configuration implementations:

• Cloudflare - DDoS protection is one of the primary reasons we use Cloudflare (along with best in class DNS), which we have enabled (Cloudflare proxy protects all of our primary domains and sub-domains).
• AWS - Our primary infrastructure workload provider; we implement AWS WAF, AWS Shield and other AWS services designed to specifically mitigate attacks like this. Additionally, our web servers are behind both API Gateway and Load Balancers.
• Vercel - We leverage Vercel for our front-end deployment and hosting, and we leverage the Vercel firewall for DDoS Mitigation.
• Google - Although we don’t currently host major workloads on Google Cloud, our service is highly dependent on Google Calendar, so if Google Calendar is down, Reclaim is significantly impacted. Luckily, Google can leverage their own infrastructure for defense.

Furthermore, we implement various vulnerability scanning tools at multiple layers in our deployment pipeline (ie: CI, Container Builds, SAST) and are actively watching for this, or related CVEs. This is in addition to our regular web vulnerability scans, and our penetration test, both of which are validated by our SOC2 audit (if you would like a copy of our report, please ask).

We pride ourselves on being very transparent with our InfoSec program and controls, and are committed to always improving our security measures and posture. If you would like additional details about any of this please feel free to reach out to us via email at [email protected] – a real human will respond!

Additional Resources

If you would like more technical details on the HTTP/2 Rapid Reset Attack, and specific actions taken by the mentioned infrastructure providers, please see the following links:

• HTTP/2 Rapid Reset: deconstructing the record-breaking attack by Cloudflare
• How AWS protects customers from DDoS events by AWS
• How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack by Google Cloud
• Strengthening Vercel’s Infrastructure against HTTP/2 Rapid Reset Attacks by Vercel