Capital One Breach Conviction Exposes Scale of Cloud Entitlement Risk
To protect against similar attacks, organizations should focus on bringing cloud entitlements and configurations under control.
The recent conviction of a Seattle tech worker accused of carrying out a cyberattack against Capital One is not the end of the story. The trial showed how one person could perpetrate a massive data breach by exploiting misconfigurations and excessive privileges common in many cloud environments.
In the wake of the attack — and the resulting data breach — Capital One was fined $80 million by the federal government and settled customer lawsuits for $190 million. This should give organizations an incentive to put measures into place to avoid the same mistakes.
The attacker, who was a former employee of Amazon Web Services (not employed by AWS at the time), built a tool that allowed her to scan the AWS platform for misconfigured accounts. She used anonymizing services such as the Tor Network and IPredator VPN to hide her IP address.
The attacker carried out a server-side request forgery (SSRF) attack that enabled her to trick a server into making calls crafted on a misconfigured Web application firewall (WAF). This allowed the Capital One attacker to easily extract and exploit the machine's credentials and gain access to sensitive customer data such as names, addresses, and Social Security numbers.
Lateral Moves and Least Privilege
This case illustrates just how vulnerable cloud systems are to entitlements and misconfigurations. The hacker was able not only to exploit a misconfiguration in the WAF to access the system, but also to then obtain privileged credentials, move around to uncover data buckets, and then exfiltrate that data.
An MIT Sloan case study on the breach concluded that "it is very likely that Capital One had insufficient Identity and Access Management (IAM) controls for the environment that was hacked.” The study also noted that the incident could have been prevented by periodic reviews of user configurations to ensure that access controls were using the principle of least privilege correctly.
Least privilege, as the name implies, dictates that users and service identities can access only the resources and applications they need to do their jobs and no more. This lets organizations operate with agility while capping risk to the company and its customers. In the case of Capital One, the IAM role of the compromised WAF machine had access privileges beyond what was necessary for its functions.
This case is a good example of how easy it can be to find vulnerabilities and exploit them to open a backdoor into a company — even one that seems well-protected. Workloads can be compromised in so many ways that it's impossible to make them hacker-proof. Even the best efforts to patch and update software, secure network access, and implement other security best practices can leave gaps that a hacker can exploit.
Once inside, an attacker's ability to move laterally, undetected, defines the "blast radius" or extent of the damage. The best way to mitigate lateral attacks is to control access by rightsizing the permissions granted to human and machine (service) accounts. In the Capital One case, the hacker was able to use an identity with access permissions to sensitive user records the role clearly didn’t need.
The complexity of cloud environments makes applying least privilege policy challenging. Native tools do not provide the required visibility into permissions for proactive risk mitigation. In addition, the much-discussed cybersecurity talent gap means most organizations are understaffed and lack cloud expertise.
As a result, permissions management doesn’t get the attention it deserves. In fact, nearly 60% of CISOs and other security decision makers say lack of visibility, as well as inadequate identity and access management, are major threats to their cloud infrastructure. In a recent survey by IDC, respondents cited access risk and infrastructure security among their top cloud security priorities for the next 18 months.
Rightsizing permissions is doable if an organization's security and development teams can identify excessive entitlements and know how to create a least-privilege policy that will allow workloads to effectively function. This can be accomplished using the right blend of technology, processes, and procedures. Consider the following best practices to bring cloud entitlements and configurations under control:
People: Give someone in the organization responsibility for implementing a least-privilege architecture.
Process: Establish a regular cadence for reviewing and remediating entitlement risk in your organization, including access reviews for human users and remediation of unused privileges for services.
Technology: Deploy technology that can continuously monitor entitlement risk, automatically remediate problems, and identify anomalies at cloud scale.
Organizations can learn valuable lessons from this case and the financial consequences of not minding their cloud Ps and Cs — namely, permissions and configurations.
About the Author
You May Also Like
DevSecOps/AWS
Oct 17, 2024Social Engineering: New Tricks, New Threats, New Defenses
Oct 23, 202410 Emerging Vulnerabilities Every Enterprise Should Know
Oct 30, 2024Simplify Data Security with Automation
Oct 31, 2024