Re: On classifying attacks

[Gadi Evron <ge () linuxbox org>]

David M Chess wrote:
> But many of us *love* to argue about taxonomies and word meanings (it's 
> cheaper than booze anyway).  *8)
>
> To my mind, if the attacker needs to be logged into an account on the 
> machine being attacked then the vulnerability is local; if the attacker 
> just has to be able to push bits to a port then it's remote.  If the 
> attacker has to trick a legitimate user into doing something (including 
> going to a particular remote site) then it's a Trojan horse.  Not hard and 
> fast boundaries (what if the attacker has to first push some bits to a 
> port and then fool a user into clicking on a link in some email and then 
> log into a local account?), but to first order...
>
> Calling an SQL injection a "Trojan horse vulnerability" sounds a little 
> odd, I admit.  But until something better comes along?
>
> DC

I spoke about this problem extensively with a few friends since this 
post came up, and a few suggestions came up:
1. A user-assisted remote attack.
2. A client-side remote attack.

I.e., we can add "user assisted" as a class like "local" and "remote", 
or add types (think ICMP here).

I.e., remote or local, then, client-side, user-assisted, etc.

This is just to put these out there again and somehow come up with a 
short generic list of just a few terms to help us along. If we create a 
full taxonomy again everyone will ignore it.

Here's a quick initial attempt:
Vulnerability Class
1. Local
        The code runs locally and initiated locally for a purpose such
        as privileges escalation and/or code execution.
2. Remote
        The code runs locally but initiated remotely, for any purpose
        from access gaining to a combined attack with privilege
        escalation or code execution.

Vulnerability Types [Optional]
These are more of understanding rather than descriptions.
1. Client-side
        The vulnerability is on a client (such as Internet explorer) but
        by no action initiated by the user by social engineering or
        other means, i.e., automatically exploited.
2. User-assisted
        User had to go to a web-site or click on an attachment as
        instructed by the attacker.

Questions remain:
- How does one treat an SQL injection?
        It is client-side, but doesn't affect the Browser directly but
        rather the database. This is remote but not an exploitation/etc.
        issue.
        Can we treat these as configuration issues? These are still
        input validation mishandling matters. Should it be called remote
        but then set to type: Poisoning?

- I.e. do we classify vulnerabilities by severity? Determining said 
severity is a difficult matter which is why remote/local works so well.

- Do we also try and treat general terminology so that we all use the 
same language? As in, privileges escalation, directory traversal, etc. 
and should these, like the possible "poisoning" be Types, which would 
suggest they would still be "remote". Should remote be saved for "code 
executions"?

        Gadi.