The Capital One Breach: An AppSec Perspective
By now, I’m sure that many, if not all of you are aware of the recent Capital One breach. If you are, great? If not, you’ll be brought up to speed after finishing the next sentence. An attacker gained access to approximately 140,000 Social Security Numbers, 1 million Canadian Social Insurance Numbers, and 80,000 bank account numbers, in addition to the tens of millions of credit card applications, and an undisclosed number of people’s names, addresses, credit scores, credit limits, balances and other information.
When any breach like this occurs, the question that immediately pops into my mind is, “How? How did this happen?”. I then advance to the “probably social engineering or stolen credentials” thought, since that’s been a consistent pattern we’ve seen in many of these data breaches. I suppose, as with many things that have evolved over the past 15 years, we’ve been (almost) desensitized by the media coverage on Social Engineering and how it’s a primary cause of most breaches.
For instance, according to the 2019 Verizon Data Breach Investigations Report (DBIR), the top three tactics used in data breaches are: Involved Hacking (52%), Involved Social Engineering (33%), and Involved Malware (28%). The DBIR further details the “top hacking actions” in breaches:
As we can see, the report identifies the use of stolen credentials as the “top hacking action”, while the other Application Security vulnerability percentages, such as Exploit vuln, Buffer Overflow, Abuse of Functionality, Remote File Inclusion (RFI), and SQL Injection (SQLi), are very low (at or below the 20% mark).
To me, that’s exactly why this breach is different than the rest. According to the court filing, “A firewall misconfiguration permitted commands to reach and be executed by that server, which enabled access to folders or buckets of data in Capital One’s storage space at the Cloud Computing Company”. The court filing goes on to state the commands sent to the server:
- Compromised the credentials of an account named in the filing as *****-WAF-Role;
- Listed contents of storage buckets; and
- Extracted and downloaded the contents of the storage buckets.
These statements confirm the attacker stole the credentials and used them to breach the information stored within Capital One’s cloud storage. I can’t help but think about firewall, Web Application Firewall and device security overall…..and how the OWASP Top 10 2017 A6-Security Misconfiguration covers this scenario entirely. This breach appears to be a mix of insider threat and security misconfiguration.
Thinking about this from an Application Security perspective, knowing how many WAFs I’ve personally bypassed throughout my career in order to start the actual application testing, I dare to wonder, “how many organizations depend on Web Application Firewalls?”, “how many of those organizations use Web Application Firewalls as a single-line of defense?” and “how many organizations stress test the Web Application Firewalls to ensure they are providing the expected level of protection?”.
Attacks against an application can get through a well-configured Web Application Firewall, and if a determined attacker targets your application relying on that WAF for its only protection, it’s most likely going to get compromised. Deploying a WAF has never meant that your application or server is suddenly secure, and no one considers a Web Application Firewall to be a long-term solution for all those vulnerabilities hanging out in your web application. Relying on a WAF to secure applications is like relying on Anti-virus to prevent malware and ransomware infections on your servers and desktops….. we’ve all seen how effective that strategy can be.
Yes. Attackers will get around automated controls. They are actively trying right now. The solution? Well, that’s been around since I’ve been professionally immersed in the security industry (early 2000s): Defense in Depth. The use of multiple controls to defend an asset is what that boils down to. It’s logical, layered, effective and absolutely necessary.
I’ll wrap up with a few (more) thoughts on the foundation to a Defense in Depth strategy that every organization should at least have in place:
- Any application that handles sensitive information should introduce security as early in the development lifecycle as possible.
- Applications should be threat modeled to identify vulnerable entry points, what data is handled and gain a solid understanding of data flows.
- Applications must have on-going system and application vulnerability scanning, and at a minimum, depending on the associated risk, quarterly code reviews and annual, in-depth penetration testing.
Until next time, we’ll get the popcorn ready, you keep fighting the good fight and if you need any help along the way, you know how to find me!
References:
https://github.com/vz-risk/dbir/blob/gh-pages/2019/report_figures
https://www.capitalone.com/facts2019/
https://www.justice.gov/usao-wdwa/press-release/file/1188626/download
https://krebsonsecurity.com/2019/07/capital-one-data-theft-impacts-106m-people/
https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration
https://github.com/vz-risk/dbir/blob/gh-pages/2019/report_figures