“Capital One discovered a data breach within their Amazon Web Services (AWS) cloud infrastructure in July 2019. How could it have possibly been avoided?
How the Capital One Breach Could Have Been Avoided With Application-Layer Data Encryption
In July 2019, Capital One became aware of a data breach inside their Amazon Web Services (AWS) cloud infrastructure. A security researcher found social media posts describing the attack, and after investigating the breach, the company discovered that the attacker was able to steal the personal information of approximately 100 million individuals in the United States and 6 million in Canada.
The information stolen was data routinely collected by Capital One during the credit card application process. For many businesses, collecting this type of information is standard practice, and the data collected is often stored in the cloud and secured by an array of security technologies. If security defenses are breached and the data isn’t encrypted properly or the encryption key is accessible, the data can easily be stolen.
This was the case for Capital One. Had the company taken advantage of application-layer data encryption, however, the breach could have been better defended against.
Inside the Capital One Breach
The Capital One breach involved sensitive data that was stored in the financial institution’s AWS deployment, which was protected against attacks by the ModSecurity open-source web application firewall (WAF). But a configuration error allowed the attacker to take advantage of a server-side request forgery vulnerability in the WAF. This type of vulnerability allows the attacker to send traffic to the WAF, which then sends traffic to another endpoint on its behalf. Since the WAF is often located within or at the perimeter of the trusted network, it has access to resources an external user can’t normally reach — in this case, customers’ personal information.
The attacker exploited the ModSecurity WAF vulnerability to relay requests to the AWS metadata service, which is designed to provide temporary information to a cloud server, including current credentials for any resource the server has access to.
Unfortunately, in this particular instance, the ModSecurity WAF was assigned too many permissions, including the ability to list and read all files stored within Capital One’s cloud deployment. By leveraging these permissions, the attacker was able to access all the data stored within Capital One’s AWS deployment, including customers’ sensitive financial data.
Key Takeaways from the Capital One Breach
Though the data breach placed Capital One in a position no organization wishes to be in, it did reveal important lessons that can help other organizations avoid similar incidents in the future.
Encrypting Data Isn’t Enough
In many cloud-based data breaches, failure to enable data encryption is one of the prevalent security failures. Any time an individual or company stores data in the cloud, they are placing data on third-party infrastructure that is accessible to the public through the Internet. The cloud infrastructure may be secured by a number of security technologies, but if an adversary manages to break through and gain unauthorized access to unencrypted data, the data can be easily stolen.
Capital One, however, claims to have encrypted their data. A statement released by the company stated, “We encrypt our data as a standard. Due to the particular circumstances of this incident, the unauthorized access also enabled the decryption of data.”
This statement underscores the importance of not only encrypting data but ensuring the most effective data encryption strategies are employed. One of the most common reasons for encryption failures is the poor management of encryption keys. If an attacker can gain access to the encryption keys — or can access decrypted data — then encrypting the data is a wasted effort. One of the best ways to ensure an attacker can’t access encryption keys or decrypted data is to limit the number of people and applications that have access to it by following the principle of least privilege.
The Importance of Least Privilege
The principle of least privilege states that a user or application should only be granted the level of privilege required to fulfill job their responsibilities. So, unless an application needs access to a particular dataset in order to perform its intended job, it shouldn’t have access to that data.
A failure of least privilege was a major contributor to the Capital One breach. The WAF that was exploited had full access to the data within the AWS instance, despite the fact that the WAF didn’t require this level of access to perform its duties. The assigned permissions were likely a security oversight, but the breach demonstrates that a failure to properly configure security controls — including for security solutions like a WAF — can leave an organization vulnerable to exploitation.
Strengthen Defenses and Enhance Encryption Strategies With Application-Layer Security
Many organizations choose to encrypt data at the disk or volume level to protect data at rest. While this provides protection against threats from unauthorized users or applications, they’re generally effective against modern, persistent adversaries.
Application-layer encryption, however, enhances the protection of data at rest because the data is encrypted by the application using it. So, encryption/decryption keys are only accessible to the application itself — not connected third-party applications. This limits the organization’s attack surface since an attacker can only access encrypted data via certain functions within an application.
How Application-Layer Security Could Have Helped Capital One
In the case of Capital One, the organization’s encryption solution wasn’t enough to stave off the attacker. Application-layer security could have helped mitigate the breach because the attacker did not exploit the application that owned the data but another, third-party system (the WAF) that had access to the information. With application-layer encryption, the WAF would still have had access to the encrypted data stored on the server, but it wouldn’t have had access to the encryption key. Only the application that owned the data would have had access to that.
It’s important to note that under most data protection laws, a breach of encrypted data without a leak of the corresponding key is a non-reportable event. In other words, if the attacker stole encrypted data with no way to decrypt it, the organization doesn’t need to report it. So, it’s essential for companies to encrypt data in the right way — through application-layer encryption — to avoid or minimize the impact of data breaches and properly protect their customers’ data.” Wias Issa
