Threat Classification

or: How I Learned to Stop Worrying and Love Web Application Threat Classifications

While working on the WASC Threat Classification v2.0 project, I got to think about the subject of classifying web application threats once again… You see, I have been dealing with Web Application Security Threat Classification since I started working on AppScan, approximately 7 years ago. back then (the Sanctum days), things were a lot simpler, the threat classes that were used in the product and in presentations, were proprietary, and were invented mainly for educational and marketing purposes.

The original Sanctum classification was known as the “10 types of hacks”:

The "10 Types of Hacks":

1. Hidden Manipulation
2. Cookie Poisoning
3. Backdoor & Debug Options
4. Buffer Overflow
5. Stealth Commanding
6. 3rd. party misconfiguration
7. Known Vulnerabilities
8. Parameter Tampering
9. Cross Site Scripting
10. Forceful Browsing (not to be mistaken with Directory Listing, this is actually the ability to access files that were not intended to be accessed by web users)

From the first day I laid my eyes on this classification system, it was obvious that it was severely flawed. Some classes, where actually sub-classes of others, for example:

• XSS can be classified under Parameter Tampering, or even sometimes Cookie Poisoning
• Buffer Overflows can occur in Cookies (Cookie Poisoning), or in a parameter (Parameter Tampering)
• etc.

One of the main flaws of this technique (other than the class redundancy) , is that whoever invented it, never decided on how he/she are going to classify the threats.

• Did they classify threats according to the hacking techniques used by the hacker? (e.g. Parameter Tampering)
• Did they classify threats according to the weakness on the application's side? (e.g. 3rd. party misconfiguration)
• Did they classify techniques according to the attack outcome/goal?

Back then, we tried to suggest a new system for categorizing web application attacks, we called it:

The "J" types of hacks:

The main difference between the J-types of hacks, and the 10-types of hacks, was that the J-types, was classified according to the outcome of the attack, and not according to the technique used by the hacker. The types were:

• Information gathering - Examples: path disclosure, error messages mining
• Script source disclosure - Examples: +.htr, ::$DATA, Translate: f (HTTP), appending .BAK to script files.
• File download - Examples: adding ../../../../boot.ini to the PATH, sending ../../../../boot.ini as a parameter value.
• Directory listing - Example: Chopping the path of a request for directory indexing
• Session hijacking/impersonation - Example: Session cookie manipulation, Cross site scripting.
• Command execution - Examples: Perl's pipe in a parameter, IIS's double decoding and Unicode issues.
• Denial of Service. Example - overlong URL, overlong parameter value, overlong HTTP header.
• Privilege Escalation - Example: e.g. requesting /phpmyadmin/ to get a database console.
• Database query manipulation - Example: Injecting various SQL queries
• e-Shoplifting - Example: price mutations, other logical flaws

Other than being extremely naive (we’re talking about 2001 here), and missing some of the “modern” attacks that did not exist in those days, this system seemed pretty solid back then (yea right!)
Pay attention to the “Denial of Service”, we’ll get back to it in a few minutes…

Fast forward to more recent times, WASC introduced the Web Application Threat Classification Project (in which I participated), and it is time to refresh the project, and start working on v2.0. In one of the email threads, we have noticed some problems in the classification system. To make a long story short, here's an email I've issued after noticing the problem:

I think the bigger issue here, is that we need to decide if this project classifies attack techniques or weaknesses. I don't believe it should classify both under the same umbrella. The term "Threat" might have been an unfortunate choice, as it is ambiguous in this context. Actually, I have been thinking about something a bit more troubling - what happens if a certain attack technique, can exploit more than one "threat" - my best example is:

1. SQL Injection, which is used to bypass the login page (e.g. ' or 1=1--). This would be classified under "Authentication Bypass"
2. SQL Injection, which is used to execute a remote command on the DB server (e.g. xp_cmdshell), which would be classified under "Command Execution"

Here's my suggestion for unraveling this knot:

1. We change the name of the project to "Web Application Attack Classification" (the same attack can be classified under several categories, depending on its use)
2. We create a different project called "Web Application Weaknesses Classification"
3. We can create a mapping between #1 and #2 (probably would be many-to-many)

In addition, the WASC TCv2, classifies some threats that are actually Attack Goals (outcome) for example - Denial of Service (DoS), which is an outcome, and not an attack technique per se. DoS can be performed in many different ways -

1. SQL Injection - drop the entire database, and deny service from users
2. Buffer Overflow - perform a buffer overflow attack that crashes the application or the web server
3. Endless application loop - exploit an endless loop condition in the application to consume resource
4. etc.

DoS should not be categorized alongside classes such as Injection Flaws, Buffer Overflows, etc. In addition, if DoS is classified as a threat, then why shouldn't "Data Theft" be classified as one also? there's a lot of resemblance between the two.

So what is the moral of this post? I'm not sure...
I guess the WASC TCv2 can do the job at the moment, even if it is not completely accurate. BTW, those who want to go hardcore on accuracy, should check out the MITRE CWE project, it is VERY comprehensive, but also very exhaustive. Maybe there's no way around it - classifying web application threats is not that trivial.

Maybe in one of the next posts, I'll talk about other classification systems that are out there.