Re: On classifying attacks

[Indigo Haze <hazer () chipshot net>]

Just my $0.02 on the topic, but there are multiple kinds of "remote
exploits"

There's remote-active, where the exploit is carried out against a system
actively (either manually or via an automated process), such as your
example for BIND and various worms vs Windows (CodeRed, Nimda, MSBlast,
etc).

There's remote-accessible, where the exploit isn't activated directly
from remote, but is still manipulated via remote, such as your EMail
trojan example. If I couldn't get the code from remote on to the system,
there would be no exploit. The initial "remote-active" exploit in this
case would be the social engineering aspect of getting the user to open
the email I sent.

Then you get into "local exploits" which require direct (and sometimes
physical) access to the device in question. Could I have walked up and
downloaded the trojan in question and manually executed it? Sure.
Anything in the 'remote-accessible' region would be repeatable as a
local exploit while not everything in 'remote-active' could be.

The answer ultimately is: There's a LOT of gray out here... Exploits are
exploits. They're generally all bad and need to be handled properly when
encountered.

Derek Martin wrote:

> The issue has come up on bugtraq before, but I think it is worth
> raising it again.  The question is how to classify attacks against
> users' client programs which come from the Internet, e.g. an e-mail
> carrying a malicious trojan horse payload.  The reason this is
> important is because we judge how serious a particular vulnerability
> is based on how it is classified.  We normally ask two main questions:
>
>  - Is this a root vulnerability, i.e. does it have the potential
>    grant the attacker the privileges of the system management account?
>
>  - Is the vulnerability remotely exploitable?
>
> The latter is a question which, when an answer is attempted,
> sometimes raises debate.  The case of the trojan e-mail is a prime
> example of this.
>
> Some are tempted to call this a remote exploit.  The payload finds its
> way to the attacker's machine via a network, after all...  The
> attacker isn't logged in to the victim's machine.  Security
> researchers are also eager to publish remotely exploitable
> vulnerabilities, perhaps because such a vulnerability is generally
> considered to be much more severe than one that is not, and thus more
> notariety comes with publishing such a vulnerability.
>
> This kind of attack has a name already: it is a trojan horse.  A
> malicious payload is disguised as an innocuous e-mail, usually with an
> attachment.  Once the user views the e-mail, or possibly even when the
> mail client tries to display headers in the message index, a bug is
> triggered which unleashes the payload on the poor unsuspecting user.
> But is this a remote exploit?
>
> Examine what is happening when the exploit is executing.  The payload
> is already on the user's system.  It was delivered via some MTA
> (possibly the same program the user uses to read mail, possibly not)
> onto the user's filesystem.  This is the remote part.  But, usually,
> at this point there has been no exploit.  Only after the user opens
> the mail, or looks at it in the message index, does the exploit
> happen.  The payload is already local to the machine, and it is the
> action of a local user which triggers the exploit.  It is a passive
> attack, launched by an attacker who can only HOPE that the user will
> fall into his trap, even if he knows the user is using vulnerable code.  
> Nothing the attacker can do remotely will force the exploit to be
> triggered.  Only once the user has acted will the payload become an
> exploit.  This is not truly a remote exploit.
>
> By contrast, look at a remote exploit against BIND.  An attacker
> launches the attack, which is an active attack...  The attacker sends
> data directly to the running named daemon, in order to exploit some 
> bug in the program.  The actions of the attacker, if he is successful,
> are the direct cause of the compromise.  Once the DNS server software
> has been started, no intervention is required by a user on the local
> system to effect the exploit.  This is a true remote exploit.
>
> What is clear is that e-mail trojans, and other kinds of attacks which
> are similar in nature, ARE more of a threat than what we normally
> think of as local exploits, and should be treated as such.  They have
> some similar characteristics to remotely exploitable vulnerabilities:
> they can allow an attacker who normally would not have authorized
> access, or even physical access, to gain access to the system.  But
> they are not as severe as truly remote exploits, because often (if not
> most of the time) careful users can avoid the affects of such an
> attack, even though they may be running vulnerable code.
>
> So let's return to the questions we ask, when deciding how severe an
> attack may be.  Perhaps what we need is not to call these remote
> exploits, but to ask a new question:  Does the vulnerability make my
> system susceptible to trojan horse attacks?  These vulnerabilities
> really should answer "no" to the remote exploit question, but "yes" to
> this new question.  A yes answer here clearly indicates a more severe
> threat than a local exploit, but somewhat less of a threat than a
> truly remote exploit.  Assessing the threat properly helps everyone.
>
>