Do CapitalOne Shareholders Have a Case Against AWS?

An adhesion contract (also called a "standard form contract" or a "boilerplate contract") is a contract drafted by one party (usually a business with stronger bargaining power, like say AWS who owns 48% of the public cloud market) and signed by another party (usually a consumer in need of goods or services with weaker bargaining power, like say CapitalOne).

Adhesion contracts are commonly used for matters involving insurance, leases, deeds, mortgages, automobile purchases, and other forms of consumer credit, yet these days are frequently used for cyber-related “contracts” like Terms of Use and Shared Responsibility agreements.

Courts carefully scrutinize adhesion contracts and sometimes void certain provisions because of the possibility of unequal bargaining power, unfairness, and unconscionability.

Factoring into such decisions are the nature of the agreement, the possibility of unfair surprise, lack of notice, unequal bargaining power, and substantive unfairness. Courts often use the “doctrine of reasonable expectations” as a justification for invalidating parts or all of an adhesion contract with the “weaker” party not being held to adhere to contract terms that are beyond what the weaker party would have reasonably expected from the contract, even if what he or she reasonably expected was outside the strict letter of agreement.

When the CapitalOne breach heads toward one of the many class-action and shareholder lawsuits in the coming months, what will matter most in determining AWS liability is the contractual arrangement between AWS and Capital One, which on its surface, appears to tilt liability issues in favor of AWS.

On the other hand, The AWS Customer Agreement does include a provision about AWS’s responsibilities, which could arguably require that AWS maintain appropriate firewall default configurations that would thwart a SSRF attack.

Section 3.1 of the AWS customer agreement states:

3.1 AWS Security. Without limiting Section 10 or your obligations under Section 4.2, we will implement reasonable and appropriate measures designed to help you secure Your Content against accidental or unlawful loss, access or disclosure.

So, what does “reasonable and appropriate measures” mean?

According to Evan Johnson, the manager of the product security team at Cloudflare (who is about as well-versed in this domain as anyone on the planet):

“The [SSRF vulnerability] is common and well-known, but hard to prevent and does not have any mitigations built into the AWS platform . . . The impact of SSRF is being worsened by the offering of public clouds, and the major players like AWS are not doing anything to fix it . . . In my opinion, it’s clear that AWS’ product offering is not complete since this is a major and recurring problem amongst their biggest customers. AWS should do something about this because IAM [identity access management] is the root of all security within AWS.”

Johnson additionally said in an interview with KrebsOnSecurity,

“There’s a lot of specialized knowledge that comes with operating a service within AWS, and to someone without specialized knowledge of AWS, [SSRF attacks are] not something that would show up on any critical configuration guide.

?You have to learn how EC2 works, understand Amazon’s Identity and Access Management (IAM) system, and how to authenticate with other AWS services. A lot of people using AWS will interface with dozens of AWS services and write software that orchestrates and automates new services, but in the end people really lean into AWS a ton, and with that comes a lot of specialized knowledge that is hard to learn and hard to get right.”

And Johnson is not alone on this issue.

Many in our community believe that SSRF threats on AWS remain a known weakness and AWS has been repeatedly asked to improve measures for SSRF defense. It is widely held that not only could AWS fix the problem with updated WAF default configuration settings and some clear customer communications, but AWS owes it to its customers as custodians of its customers’ data to make sure it is fixed.

And, of course Oracle and Microsoft have held a similar view for the last 5 years as well.

The actual contract between AWS and CapitalOne is not a public document, so we don’t know how it is written or what accommodations it contains but based on the initial response from AWS which threw immediate blame across to CapitalOne, it might be standard boilerplate adhesion-style.

Which is interesting, because CapitalOne is more than just an AWS partner. Based on their testimonials and praise for AWS, they more like cheerleaders, marketers and promoters. So, it would seem likely that CapitalOne received some level of compensation or other form of consideration (e.g. a discount or other customer VIP status) — and that their contractual relationship is heavily customized.

Unless the folks in CapitalOne’s legal department either didn’t get the memo or don’t like marketing quid-pro-quos, at least in contract-language.

In addition to the tenuous arguments about liability owing to a potentially unfavorable adhesion ruling, AWS might be extra cautious about another wild-card in this game. Paige Thompson, the essentially self-confessed and alleged perpetrator of this breach, worked for AWS in the past and specifically in their S3 cloud storage technology group, which would have provided her with “insider” information about their architecture and data structures.

From a shareholder or customer point-of-view as plaintiffs, an easy argument could be made (to a jury) that, through her knowledge of AWS’s storage architecture, she had privileged information about Capital One’s firewall weaknesses.

Now, technically we know this is nonsense. Any engineer working around S3 containers would have had knowledge of what is now the well-known single-line command known as the AWS SSRF (Server-Side Request Forgery) exploit, that exposes AWS credentials on any EC2 system, and could have executed the same hack. In fact, the command and its functionality is included in their documentation for all to see.

There is also well-documented and substantial evidence that the exploit had been around for years and had been widely discussed in the InfoSec community. A Swiss security engineer described an attack two years ago in a blog post specifically titled, “Abusing the AWS metadata service using SSRF vulnerabilities.” Netflix, one of AWS’s biggest customers, became so concerned that in 2018, they published clear research on credential compromise relating to AWS cloud configuration.

On top of that and lending more fuel to the plaintiff’s fire against AWS, a Netflix senior security software engineer reacted to the Capital One breach by reporting that Netflix had asked AWS to address its exposure to SSRF, and said, “Netflix asked AWS to follow the GCP [Google Cloud Platform] protocol and require a special header for metadata service requests [to defend against SSRF attacks]. Unfortunately, we didn’t get a satisfactory response.”

If AWS in fact received a request from Netflix to add critical SSRF security protection and was negligent by ignoring it or in the least, failed to pass along concerns like these to its other customers (Capital One, for one) then liability could easily shift from Capital One to AWS – and class actions against AWS would explode.

After all, who has the deepest pockets?

Additionally, as if more accelerant is needed for an already out-of-control crisis messaging storm, AWS acknowledged that it could be more proactive following the CapitalOne breach and has now begun scanning public IP addresses to try to detect misconfigurations. They also announced they will do more to ensure its anomaly detection services are “more broadly adopted and accessible in every geographic region” where the company operates and will "redouble" its efforts to help customers set the least permissive permissions possible.

These statements are public acknowledgements that AWS could have done more to protect its customers’ data than they did with CapitalOne.

Another interesting fact from the plaintiff’s point of view is that in February, 2016, Tom Killalea, the former Chief Information Security Officer at Amazon.com was appointed to the CapitalOne Board of Directors. Perhaps the reluctance to come entirely clean at the outset in terms of attempting to direct liability by the injured party toward AWS may lie in the coziness of the relationship between the two companies and might be interpreted by jurors as a form of collusion to shift the blame entirely onto the perpetrator and away from the custodian, AWS.

So, from the plaintiff’s perspective, we have a shared responsibility contract that will probably be rendered unenforceable due to the adhesion issues; a cozy relationship between AWS and it’s potentially co-victim, a self-admission that AWS could have done more and evidence as to what that “more” is in that they have proceeded to do just that, a witnessed failure to add critical protection and a willful rejection of a customer request to do so, known and acknowledged vulnerabilities that existed for at least two years without AWS’s attention or correction and repair, a former employee with insider knowledge that was used in the perpetration of the breach who was terminated for workplace “issues” and well-respected and highly regarded industry experts claiming that AWS’ product offering is not complete and is in fact posing a dangerous risk to their customers’ data integrity.

Any jurist could easily conclude that AWS should have 1) maintained better default firewall configuration settings, 2) fixed known weaknesses in its API-handling feature known as the Metadata service 3) issued more comprehensive and explicit customer communication and alerts, and 4) in the future, restructure its shared responsibility contract with emphasis on the doctrine of reasonable expectations so that both parties can share equally in responsibility for negative outcomes.

In other words, the preponderance of evidence suggests that a clear judgement against AWS is not only just possible, it now appears likely.