Date: Fri, 15 Jul 2005 18:22:09 -0500
From: Indigo Haze <hazer@...pshot.net>
To: bugtraq@...urityfocus.com
Subject: Re: On classifying attacks


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.
>
>  
>

Powered by blists - more mailing lists