Re: On classifying attacks

[Mihai Amarandei-Stavila <mihaia () gmail com>]

On 7/16/05, Derek Martin <code () pizzashack org> wrote:
> On Fri, Jul 15, 2005 at 06:40:42PM -0500, James Longstreet wrote:
> > On Jul 14, 2005, at 9:39 PM, Derek Martin wrote:
> >
> > > This kind of attack has a name already: it is a trojan horse.
> > <snip>
> > > But is this a remote exploit?
> >
> > No, it's not an exploit at all.  Systems are not vulnerable to it
> > unless a local user runs an executable.
>
> It seems to me your statement can't be correct, because this is ALWAYS
> the case. A local exploit requires that a local user run an
> executable.  A remote exploit requires that a local user run an
> executable, even if that is accomplished merely by booting the system.
> All exploits require running code, and code doesn't magically start
> itself...  Running code is required, because it is the very running
> code which is being exploited.
I think we have some confusion here. We're talking about two distinct
types of attacks, which do not belong in the same category:
* A user receives an e-mail containing a Trojan executable file, a
.exe, a .scr, etc. This is not about exploitation. Is about tricking
the user into running what we want. It is similar to telling someone
they should run del c:\*.*(rm -rf /) to scan for viruses. If I am able
to trick a user into executing this commands I'm not exploiting
anything but his trust and lack of knowledge. It is not an exploit
from a security point of view and has no associated vulnerability.
This attack is pretty much independent on the [e-mail] client we use.

* A user receives an e-mail that exploits a security flaw in the
client software. An e-mail with malformed headers, that exploits a
buffer overflow in a specific [e-mail] client and thus executes its
malicious payload for example. This is indeed exploitation, from a
security point of view. We have a piece of data (exploit), which
exploits a security flaw (design or code) in a specific client.

> > The only thing it exploits is trust of email (or similar vector).
>
> I think this is also not the case.  To exploit essentially means to
> use.  These attacks USE the users' trust of e-mail in order to USE a
> bug to gain access to USE the system for his own purposes...  That
> certainly seems like an exploit to me.
The word exploit has acquired a particular meaning when speaking about
IT Security. I don't think we should include exploiting user's trust
in its scope, as it would make the concept too vague.

> > Let's  imagine for a moment that there is a buffer overflow in
> > libjpeg that  allows an attacker to create a malicious JPEG which
> > can cause any  program using libjpeg to execute arbitrary code.
> > This should be  classified as a remote vulnerability.
>
> We disagree here.  The vulnerability is neither truly remote nor
> local, in the normal senses as we have defined them here.  It is a
> different kind of vulnerability altogether.  The vulnerability is one
> to automatically triggering trojan horses....  Just as in the case of
> the fabled Trojan Horse, there is no vulnerability at all until the
> local users make a decision to trust something (data in this case,
> rather than a hollowed out horse-shaped monument) from an outside
> source.  
There is a vulnerability, in the libjpeg library. There is no attack
until the local user decides to trust a particular piece of data.

> In this case, the trust is given implicitly rather than
> explicitly.  This is no different than if I handed you a disk, told
> you to run the program on the disk, and you did so -- resulting in the
> destruction of your hard drive.  Would you call this a remote
> vulnerability?  Of course not.  But the mechanism is exactly the
> same... except that some of the minor details are different.
>
> The only difference is the medium used to deliver the trojan horse is
> a network instead of a disk, and it is slightly more automated,
> because you are prone to automatically view the data out of habit.  If
> I did hand you a disk and tell you to run the program on it, you would
> probably be a lot more wary of doing so than you would of reading your
> e-mail, wouldn't you?  Especially if you don't know me very well.  But
> if you were dumb enough to do so, would you call this a remote
> exploit?  What if I gave you a disk that had an Excel spreadsheet on
> it, which contained data designed to take over your system using a bug
> in excel...  Is this a remote exploit?  I don't think so.  Now I use
> the same excel spreadsheet, but I send it to you in e-mail instead of
> giving it to you on a disk.  In all cases, I have given the data to
> you.  In all cases, there is no exploit at all, until you, the local
> user, decides to trust the data, and run broken code against it.  The
> only difference is the specific delivery mechanism, and the fact that
> the average user implicitly trusts data received in e-mail.  Because
> really, what choice do they have?

The difference between the hypothetical JPEG flaw and running programs
from a disk, besides the delivery mechanism, is that the first
exploits an actual security flaw in the image-rendering engine while
the later just exploits user's trust. The JPEG flaw exploits a certain
implementation of the JPEG rendering engine. Upon viewing a malicious
JPEG, some applications will be vulnerable while other will just pop
up a message saying the JPEG file is corrupted. The exploit is related
to a specific implementation and product. In the case of the disk,
there is no particular instance of software (code) that is being
exploited. The payload and the attack are totally independent from the
applications used (Operating System excluded). The Excel example
mentioned is again different from the disk program as it uses and
exploits a specific bug in a specific piece of software.

> But this is still not a remote vulnerability.  It is a user trust
> vulnerability, as you said yourself.  And it is a vulnerability (or
> susceptibility) to trojan horse data.  The fact that the data just
> happens to come in via a network is largely irrelevant.  A remote user
> can, IN NO WAY, effect an exploit against this kind of vulnerability
> merely by his own action.  This exploit can not happen unless you, the
> local user, do it for him.  This is the essential reason why it is not
> a remote vulnerability.

Vulnerabilities properties remain hard to pinpoint and define. A
vulnerability remains however a flaw in a piece of software, not in a
user. An attack is a series of actions enabling an attacker to disrupt
the Confidentiality, Integrity or Availability of the system.
Vulnerability!=Attack.. An attack can use vulnerabilities (libjpeg
buffer overflow) or can use user's misplaced trust (user running
e-mail attachment).

IMHO a term suited for these client-side vulnerabilities would be a
remote vulnerability requiring user interaction. It is remote as being
different from local where the attacker needs system access for its
attack and it is remote because the attacker is not placed on the
system attacked. It requires user interaction because it does :).