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