A Few Lessons from the Capital One Breach and Possible Countermeasures

A few days ago, the news of the Capital One breach was made public. Being a major financial powerhouse, 106 million customers were immediately affected by this breach and several companies are investigating possible spill-over effects. While the details of the breach are still unfolding, it is imperative to analyze the breach based on the known facts. The aim is not to blame any entity but rather to gain corrective knowledge and lessons. Here are a few lessons to be derived and possible counter-measures.

Principle of Least Privilege: It is believed that the hacker, Paige A. Thompson gained access to Capital One’s cloud infrastructure by acquiring credentials of a misconfigured VPC firewall (ModSecurity WAF). Thompson employed a SSRF attack to launch attacks against a metadata server due to this misconfiguration. But before diving into the misconfiguration issue, let’s briefly examine the principle of least privilege. A firewall (as well as other cloud resources) should have limited privileges, only as needed to function. On AWS, this principle is best implemented using Access Control Policies (ACP), which actually enforce fine-grained access control using an authorization process illustrated in Figure 1.

Figure 1: Authorization Process Illustrating Decision Making for an Access Contol Policy (source:AWS )

A key challenge with ACPs is that they are mostly created manually, thereby introducing human errors. Compare this to traditional systems like Active Directory, entities are automatically assigned privileges based on roles, groups etc. These possibilities exists on cloud systems though in more limited forms, hence requiring much more tweaking and customization. Thus, a least privileged VPC firewall would possibly have prevented the attack.

Security Misconfiguration: The issue of misconfigured cloud assets has been clamoured over and over again in the last few years. In fact, OWASP asserts this to be the 6th on its list of top 10 vulnerabilities in 2017 (A6:2017 — Security Misconfiguration). There are several reasons why cloud assets could be misconfigured: lack of adequate knowledge/skills, manual configuration procedures and due to active attacks. It’s noteworthy from the Capital One breach that misconfigurations issues are not limited to cloud buckets (e.g. the wrong ACLS in Figure 2), but could span across any other cloud assets. A typical example is case, in which a firewall rule/policy was misconfigured, thereby providing an initial foothold for the attacker.

Figure 2: Wrongly Configured AWS ACL Resulting in a Publicly Accessible Bucket

Mitigations: There are several security mechanisms for mitigating the security issues discussed above. Let's have a look at a few.

• Automated policy generation is required- policies in existing/traditional systems could be translated to corresponding access control in the cloud. A simple way to achieve this is by assigning the same permissions to employees in on-prem resources to corresponding resources in the cloud. However, this requires the translation of on-prem access control mechanisms to cloud IAM and there are no direct approaches for doing this. · We proposed some multi-cloud techniques in our research paper, AWS also provides some strategies for migrating active directory domains to the cloud.
• Continuous security monitoring and risk assessment — Cloud environments could change states in unpredictable ways: employees seldom make mistakes, attackers could compromise cloud resources and change configuration to enable attacks. Therefore, continuous, realtime security measures are required, as properly explained in this paper. Such techniques must be automated and proactive. If well designed, unauthorized changes would be detected and promptly stopped within the shortest possible time. Doing this effectively stops attacks or at least reduces the attack rate.
• Incident Response: Detecting security events is good but active and timely reaction is even better. In the case of Capital One, thanks to their subscription to a vulnerability disclosure program, a third-party security researcher hinted them about the vulnerability. Others might not be so lucky or the knowledge might come too late. Therefore, real-time analysis of security events (e.g. from AWS CloudTrail and Google StackDriver) is necessary to detect attacks and act promptly/automatically, or at least alert a human operator. Figure 3 shows CloudTrail records of attacker activities which can be continuously extracted and analyzed for incident response. Though Capital One enabled CloudTrail, the logs were most likely not retrieved for analysis thus the attacker’s activities were never detected.

Figure 3: AWS CloudTrail Showing Attacker Activities

CSBAuditor — We have designed and implemented CSBAuditor, a multi-cloud risk assessment & threat detection system that tackles the aforementioned challenges. A key feature of CSBAuditor is its ability to overcome the log delivery time lag of cloud service providers. Currently, cloud providers deliver logs only after about 15 to 90 minutes (or more) after the occurrence of events. Figure 4 is an alert produced by CSBAuditor indicating an unauthorized policy modification in on Google cloud. In this case, a service account’s role was modified, indicating a privilege escalation attack. CSBAuditor detects such attacks, and implements appropriate countermeasures such as recovering the original role i.e. the expected state. Furthermore, the example alert is further enriched and correlated with StackDriver event logs to detect Indicators of Compromise e.g. attacker’s IP addresses, account Api keys, and the attacker’s user-agent. An example result of the correlated output is illustrated in Figure 5.

Figure 4: An Alert from Our System (CSBAuditor) about an Unauthorized Role Modification on Google Cloud Platform

Figure 5: Correlated Information Showing IoC for Compromised Cloud Asset

Conclusion: We have taken a bird’s view of the recent Capital One breach to draw some lessons and proferred some counter-measures based on our research and implementations. It is notable that attacks against cloud resources are becoming more pervasive, innovative and sophisticated. Therefore, corresponding counter-measures should range from basic implementations such as correct configurations to sophisticated techniques e.g. continuous security risk assessment and incident response. Regardless of your preferred approach, it is imperative to employ layered security techniques to ensure robust security in the cloud. Thank you for reading!