Common Attack Pattern Enumeration and Classification

CAPEC User Summit Transcript - “Talking Exploits”

Navaneeth Subramanian, CAPEC/CWE Program

Session 1 - Talking Exploits | View all Summit transcripts

(06:37) Speaker: Navaneeth Krishnan Subramanian

Good morning, everyone. My name is Navaneeth Subramanian and I'm a pen tester with the MITRE CAPEC team. Some of my work in the past involved performing a multitude of security assessments for different kinds of organizations, anything from web applications and services to national elections software. So today, I'm going to be talking about exploits and specifically about execution flows and how CAPEC and execution flows can plug into the penetration testing workflow. The intent of this leadoff presentation is to set the tone a little bit, for the rest of this session, so the presenters will be coming in after me will be talking about how they use CAPEC in their penetration testing workflows. And so, before we dive into that, I just wanted to give you guys a quick overview of what CAPEC is and how execution flows work.

Next, please.

(07:47) Speaker: Navaneeth Krishnan Subramanian

We're considering a scenario which is probably way too common, which is: you work for an organization, and your organization gets hit with a massive attack of some kind, and the attack leaks sensitive information. Let's say that it exposes personally identifiable information of the employees, the members of the organization. Let's say that some of the information that's leaked includes the Social Security numbers of the users. And let's say that you were tasked with trying to find out how this happened, and what is the scale of this damage.

There are multiple routes that you can take in any sort of post attack mitigation or forensic scenario to understand what happened. Something that commonly happens in organizations where there might not have been a lot of security mechanisms that are put in place up front is that they realized that there is an importance to do a security assessment. And better late than never, so you go ahead and do a security assessment. So typically what that works like is that you have a static analysis phase, and we have a dynamic testing phase so you would leverage the tool, which is a static analysis tool that basically scans your network and tries to find out the various avenues where there is trust boundary, where user input is accepted to find out where the real weaknesses lie.

And for the purposes of this presentation, the vulnerability that was exploited in order to conduct this data leak operation was a SQL injection vulnerability, so I'll be diving a little bit into that.

Next slide, please.

(09:47) Speaker: Navaneeth Krishnan Subramanian

I chose SQL injection because, first thing, it's extremely common. And secondly, there's so many different ways that you can do a SQL injection attack.

Most of you who work in the penetration testing space or security assessments space already know what an SQL injection attack looks like. But just so that I can bring everybody onto the same page for those who might not be familiar, this is a quick introduction. So, essentially the problem lies in an excessive trust in the operations of the user. You're placing a lot of trust on to a user. You are not validating any input that they're providing to the system.

And what that allows them to do is to input text into the input field that isn't constrained by a character set, so they can essentially write code. And this code will help them break out of the context of the privilege level they have, which is that of a user, and into the context of the code that's executing underneath on the back end and essentially it allows them the opportunity to basically run code on the database directly.

If you look at the example code, the dash dash characters are used in SQL languages to essentially comment out the rest of the line of code. If the user name that you input is the one that's specified in the second and third point, essentially the operation that runs on the database is an operation where one of the conditions that it needs to meet in order to execute this operation is always going to be true. Here, one equals one will always be true. And because this is the condition that you're leveraging, this statement is always going to run and so you're going to be able to do anything from adding data, deleting, modifying anything you want, essentially.

Next please.

(12:01) Speaker: Navaneeth Krishnan Subramanian

This is the CAPEC entry for SQL injection.

I'll be going a little bit more into detail about the execution flows underneath it all, but basically, all CAPECs will have a description of the exploit, the likelihood and severity, the consequences, other related exploits that are associated.

If you can go back to the scenario that we're discussing, which is you ran the static analysis tool and you found out that the SQL injection vulnerability exists, now your job as a pen tester is: verify that this is not a false positive. What that usually means in the pen testing field is, you could go in and you would do a dynamic or manual analysis.

When we start manually testing it, this is really where the human operation side of the pen test begins.

Next slide.

(12:50) Speaker: Navaneeth Krishnan Subramanian

And anyone who's done in pen test might be familiar with this analogy. Once you get to this stage, it's essentially to choose your own adventure story: the underlying application, it's the version that it's running - the operating system that it's running, everything matters with respect to creating a successful exploit, and no two exploits are going to be the same, so there's a very, very high degree of subjectivity, that goes into a manual pen testing operation. There are some known methods - tried and tested methods - that pen testers will use, but there is a lack of standardization, which is what this entire summit is just what we're here to talk about.

Next, please.

(13:34) Speaker: Navaneeth Krishnan Subramanian

One of the funny things about working in the pen testing industry, especially when you work with developers who may or may not be super aware about the different kinds of exploits you could conduct, where certain vulnerabilities - there's a little bit of mysticism around the idea of pen testing. There's almost it's like weird magical quality to knowing how to do an exploit just because it's difficult to be standardized, so it's not widely done. And so there's a lot of ambiguity and gray area here.

But luckily we can reveal our tricks, and we don't have to worry about being ostracized by the greater community of penetration testers from ever being able to mount a stage and perform our tricks.

Next please.

Let's say you start doing the manual testing operation and, like I said, for SQL injection that there are so many different ways that you can choose to attack this system and it's useful to have all these different ways documented or standardized somewhere essentially you're asking yourself questions like where do you start? What about somebody who has no experience conducting exploits, what about developers? How would they start? If you did pick one of these exploits to start with how would you go about actually doing it?

Next slide.

(14:56) Speaker: Navaneeth Krishnan Subramanian

So this is where execution flows really come into the picture. We came up with execution flows to come up with a way to describe exploits in that procedural way

They're not meant to be exhaustive, so you can think about execution flows as being descriptive rather than prescriptive.

The general structure of an execution flow is something that helps you define the start, middle and end of a successful exploit. The start is the Explore stage where you verify that this vulnerability actually exists. So when you verify its existence you then go onto an experiment stage where you would try various things where you would change the way that you send this data, you would change the data itself to see what special characters you could include, you could try altering the input to produce specific errors that the website will give you.

It's usually a good indicator that there is a vulnerability where you input something that is maybe not in the context of what the user should have access to and instead of getting a website error you're getting database error. So instead of something saying: "your credentials are wrong”, it says "this table cannot process this information", you know fix or code or something about . So usually when you see something like that it's like green light to go ahead and try a couple of exploits, which is the final stage of it is the exploit stage so.

Essentially, at this point, you gather everything that you know about the system. You use the characters that you know achieve a certain outcome. You could even use what people in the industry uses - they're called Cheat Sheets which are a list of known exploit strings for SQL injection vulnerabilities and you can sequentially try all of them or you can manually automate write a script to try all of them in the input field and see what sticks.

So this is an execution flow of a SQL injection at a high level. So why is this important?

Next slide.

(17:05) Speaker: Navaneeth Krishnan Subramanian

So the first merit of having a CAPEC for SQL injection and having an execution flow for SQL injection is the standardization itself. We record what we see and it informs us of the historical trajectory of this vulnerability exploit as it evolves over time.

As a security person, who has worked with developers to help patch vulnerabilities in their system, one thing that I always do is to empower them with the knowledge that is required to make a successful mitigation, rather than just giving them the mitigation itself, so if developers know what the exploit looks like they can write better mitigations because they developed the system as long as they're following the right security principles. This also bodes well for the security posture of the organization that they work for generally because if they are informed about exploits and they just write more secure code overtime.

This works out well. It's a win-win situation!

Another important factor is forensics so even in this data leak scenario it's possible that this injection vulnerability has existed in this system for weeks, if not months or years, so as a security person knowing all the ways that it could have been exploited by looking at each exploit that is standardized and looking at all the related exploits with SQL injection. It gives you a number of things to look for when you are doing post intense forensics when you're looking at network traffic when you're looking at system logs - stuff like that.

Lastly, it is an academic resource.

I know that CVEs and CWEs is something that I was highly reliant on even when I was in college and I still rely on to this day. Even if for nothing else than to just understand what's going on in the security world and understanding the emerging landscape of vulnerabilities and for a given weakness there are multiple exploits. Having a standardization of those exploits will give an equal amount of value from an academic perspective.

Next, please.

(19:23) Speaker: Navaneeth Krishnan Subramanian

To help facilitate the integration of CAPEC and execution flows into the pen testing workflow we are committed to working with the community to figure out ways to make this better and one of the things that we are doing to accomplish this making execution flows more robust.

SQL injection as we saw there was one specific kind of exploit that was described so our next vision involves you know coming up with multiple ways of exploiting and then documenting those ways. We're also trying to improve the mappings that we have between CVEs, CWEs and CAPECs because as a person who works a lot with static analysis tools and as most of the vendors who are attending this summit already have CVE or CWE integration into your system. Being able to have robust mappings between them just makes it one step easier to integrate CAPEC into your systems.

The presenters after me will have a little bit more of a detailed perspective on what this looks like on an operational level.

That concludes my presentation. If you have any questions I would be happy to answer it over the course of this summit in the chat so please post them in the chat and I'll respond as if something goes on.