On classifying attacks

[Derek Martin]

--jCrbxBqMcLqd4mOl
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

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.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D


--jCrbxBqMcLqd4mOl
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFC1yHidjdlQoHP510RAvcsAJ9wQE4OrHWmdjdGjrowCt zKO+yphgCfWceB
F8d1dcO8uhgKc3gN0FrPyDQ=
=KaPg
-----END PGP SIGNATURE-----

--jCrbxBqMcLqd4mOl--

[Bryan McAninch]

I merely skimmed your post, so I apologize if the link I'm providing is not
what you're looking for. From what I read, it sounds as if you might be
looking for an attack taxonomy, or something of that nature. An entire
chapter of the Computer Security Handbook is devoted to this topic, written
by John D. Howard and Thomas A. Longstaff. This document can also be found
at CERT's website - http://www.cert.org/research/taxonomy_988667.pdf

Cheers,

Bryan

-----Original Message-----
From: Derek Martin [mailto:code@pizzashack.org]
Sent: Thursday, July 14, 2005 09:40 PM
To: bugtraq@securityfocus.com
Subject: On classifying attacks

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.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

[Derek Martin]

--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

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.

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

> Your example involving BIND is a good example of a true remote
> exploit.

Thank you! We agree on this, at least.

> A local exploit is typically categorized as one that requires
> permissions on the system to begin with, and is used to gain
> elevated permissions (such as exploiting a setuid program, or
> causing root to write files through symlink race conditions).

We agree on this too.

> This leaves one significant class of vulnerabilities, however.

This is essentially the very point of my short essay.

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

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.

> Users should be able to trust that opening a JPEG file will only
> cause certain code to run, namely decoding and displaying that
> JPEG.

Absolutely they should. But the fact that they DO trust it when it is
not worthy of their trust does not make this a remote vulnerability.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D


--0OAP2g/MAC+5xKAE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFC2Th9djdlQoHP510RAlYLAKCdMWhfeUsJblM/Ba1Qqh84mgTUbACfYlnS
Bd2rpYkmqs6tB+Ufb5KHQew=
=UjTJ
-----END PGP SIGNATURE-----

--0OAP2g/MAC+5xKAE--

[James Longstreet]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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. The only thing it exploits
is trust of email (or similar vector).

Your example involving BIND is a good example of a true remote
exploit. A local exploit is typically categorized as one that
requires permissions on the system to begin with, and is used to gain
elevated permissions (such as exploiting a setuid program, or causing
root to write files through symlink race conditions).

This leaves one significant class of vulnerabilities, however. 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. Users should be able to trust
that opening a JPEG file will only cause certain code to run, namely
decoding and displaying that JPEG.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC2El6TYcj5d9bqjoRAsMcAKCKXn5l/B7WH4B49JIidvCXz3utRgCgxIBo
xXQ3xMVvvTAZZtz7jXXd12o=
=EhoG
-----END PGP SIGNATURE-----

[Indigo Haze]

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

[Godwin Stewart]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 16 Jul 2005 12:40:29 -0400, Derek Martin <code@pizzashack.org> wrote:

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

Maybe so, however with the case of the BIND attack, the vulnerability in
locally running code (named) is being exploited by a remote attacker via the
network.

In the case of an e-mail containing malicious code, the code being exploited
(parts of the Windows kernel or whatever) is being attacked by code running
locally - on the *same* machine. In this sense it can hardly qualify as a
"remote" exploit.

- --
G. Stewart - gstewart@spamcop.net

A lot of money is tainted. 'Taint yours and 'taint mine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC2ifiK5oiGLo9AcYRAswqAJ9lPxLOVO45WpnKxWEYva 41HSbnrwCfdkGT
fEc+qbBBB4LKkzeR5bKMikg=
=yzAH
-----END PGP SIGNATURE-----

[James Longstreet]

On Sat, 16 Jul 2005, Derek Martin wrote:

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

Yes, but a trojan requires a user to run a program, not open a file.
JPEGs are an image format, not an executable format. Opening one should
display the image, not run arbitrary code.

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

But it's not a bug. A computer that runs an executable when it is
double-clicked does not have a vulnerability.

Example:

All Unix systems are "vulnerable" to loss of data through the following
exploit: an attacker sends the string "rm -rf /" through email. If the
system administrator gives this string to his shell running as root, all
data on the system will be lost.

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

It's completely different. If you gave me a program on a disk, I wouldn't
run it, because I know that programs that I run can do whatever they want
on my system. That's not because of a bug, it's because that's what a
computer does -- run programs.

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

If you gave me an Excel spreadsheet on disk, I would expect to be able to
open it and see a spreadsheet. I am allowing you to display a spreadsheet
on my system, not to run arbitrary code. If there was a bug in Excel, you
would be able to exploit my legitimate trust in Excel to run arbitrary
code.

If you gave me a program on disk and I ran it, I am giving you permission
to run arbitrary code on my system. Therefore, there is no bug. The
blame lies solely on me, not on my operating system, computer, or the
program itself.

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

Yes, but opening an untrusted image file, for example, is a legitimate use
case. I would assume that almost all of us do so multiple times a day.
Trusting a program whose job is to open JPEG files to do so is not a
vulnerability.

> Absolutely they should. But the fact that they DO trust it when it is
> not worthy of their trust does not make this a remote vulnerability.

Your logic is flawed, though. Even if we agree to disagree on whether or
not opening an untrusted data file is a trust issue or not, what makes it
a remote vulnerability is the fact that the attacker does not need
privileges on the system. Perhaps, you say, you are giving him privileges
by opening his data file. But you are only giving him privileges to open
that file, not to run arbitrary code.

[Steven M. Christey]

Derek Martin said:

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

I agree with you on the need for a third category.

Another term could be "user-complicit," which reflects the core role
that the user has in activating the vulnerability, versus the
traditional "automatic" exploitation (no human user interaction) and
"opportunistic" exploitation (attacker has no control over when the
vulnerable state occurs, as can happen in some types of information
leaks for example).

Depending on the normal channels by which the "trojan" is delivered,
the attack could be "local user-complicit" or "remote user-complicit."
For example, images are usually shared in some remote fashion, thus a
vulnerability in an image renderer could be remote user-complicit,
whereas a vulnerability that requires a local user to trick another
local user into changing into a directory with a large name would be
local user-complicit.

One small difficulty I have with associating this too closely with the
"trojan horse" terminology is that many Trojans are inserted after a
vulnerability has been exploited and access is gained, so this further
muddies the waters of an already vague term.

- Steve

[Mihai Amarandei-Stavila]

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.
>=20
> 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.
>=20
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).
>=20
> 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.
>=20
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.
>=20
> 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. =20
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.
>=20
> 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.
>=20

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!=3DAttack.. 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 :).

[Crispin Cowan]

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. The only thing it exploits
> is trust of email (or similar vector).
But it is a remote *attack*. There is no other word for it than "remote"
when the attacker is not local.

Which is not to say that the distinction Derek raised is invalid; there
certainly is a semantic difference between an attack delivered by an
e-mail, which does nothing until the user reads it or clicks on
something, and a traditional remote attack where the attacker exploits a
flaw in a program that is listening. Such a program typically is a
server (BIND, Apache, Sendmail) but could also be a client (Gaim).
Pushing the boundaries, the program could be a web browser, where the
attack does happen immediately, does not involve a Trojan, but does
still require the user to do something like click a particular URL.

So what we have is a very complicated space full of adjectives:

* Attack: doing bad stuff to someone else's stuff.
* Vulnerability: an unfortunate software flaw or configuration that
enables an attack. It might be very specific, such as a buffer
overflow vulnerability in a particular program, or it might be
very general, such as "running Outlook with administrator privilege".
* Exploit: software that automates attacking a vulnerability.
o *Note:* by this definition, an e-mail virus that leverages
the common fact that many users run Outlook as administrator
is in fact an "exploit", even if it is a weak one.
* Remote: attacker is over there somewhere, usually across some kind
of network.
* Local: attacker and victim are connected to the same computer.
o *Note:* in common parlance, this usually means that the
attacker must compose a local vulnerability with some other
vulnerability that will get them a login shell on the
machine to be attacked, or must be granted legitimate access
to the machine.

These terms are all commonly used in Bugtraq discussions, and I believe
these definitions follow common usage. Using these terms precisely is
important.

Yet none of them capture the distinction Derek pointed out, and so
perhaps we need a new term. We could say that attacks against connected
programs like BIND and Gaim are "synchronous" and attacks that involve
sending now for impact later such as e-mailed malware are "asynchronous".

Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Director of Software Engineering, Novell http://novell.com

[Adam Shostack]

On Mon, Jul 18, 2005 at 10:49:00AM -0500, James Longstreet wrote:
| > 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. 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.
|
| It's completely different. If you gave me a program on a disk, I wouldn't
| run it, because I know that programs that I run can do whatever they want
| on my system. That's not because of a bug, it's because that's what a
| computer does -- run programs.

Just as an aside, no.

Operating systems run programs and control access to resources. The
idea that any program can do anything to your system is a strange
one. Systems like Goldberg and Wagner's Janus, or Cowan and co.'s
Subdomain, or heck, even the Java security manager, impose limits on
what a program that you run can do.

That most commercial operating systems lack these sorts of controls is
unfortunate. I would really like to be able to limit what files and
directories my mail client or web browser can touch.

| If you gave me a program on disk and I ran it, I am giving you permission
| to run arbitrary code on my system. Therefore, there is no bug. The
| blame lies solely on me, not on my operating system, computer, or the
| program itself.

Again, the blame lies on your operating system for not letting you do
what you want in a common situation.

That's neither here nor there with regards to the local/remote or
credentialed/anonymous discussion. But I think that on a security
list, we should not udnerestimate the value of OS features.

Adam

[Dustin D. Trammell]

--=-mefpkHpXCSUoX20vPJ37
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2005-07-17 at 01:58 -0700, Crispin Cowan wrote:
> Yet none of them capture the distinction Derek pointed out, and so
> perhaps we need a new term. We could say that attacks against connected
> programs like BIND and Gaim are "synchronous" and attacks that involve
> sending now for impact later such as e-mailed malware are "asynchronous".

I have seen the terms "active" and "passive" used quite frequently to
differentiate between these two conditions.

--=20
Dustin D. Trammell
Vulnerability Remediation Alchemist
Citadel Security Software, Inc.

--=-mefpkHpXCSUoX20vPJ37
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBC3SlHvzar7QVmz2YRAsUTAJ49l+6caWkyeKIGXYIX8q 1sdVHSjwCglhkd
f7aYpf9pVv/j9V2c6NNwsaw=
=P8HH
-----END PGP SIGNATURE-----

--=-mefpkHpXCSUoX20vPJ37--

[Crispin Cowan]

Black, Michael wrote:
>You might try re-using the rather large effort that went into the CERT
>taxonomy:
>http://www.cert.org/research/taxonomy_988667.pdf
>
>You'll note the complete lack of "local" and "remote" in the taxonomy.
>
That pretty much tells me everything I need to know about whether I want
to use that taxonomy :)

>Remote exploit of Bind (causing "rm -r /*" to be executed):
>Attack:
> Tool: User Command
> Vulnerability: Design
>
"Design"?!

>If you really want to stick with "remote" and "local" I think you can
>define them thusly:
>Remote -- control/access of resources occurs from outside the
>machine/network
>Local -- control/access of resources occurs on the local machine (i.e.
>no network connection required)
>
Ok, but I had no trouble with those definitions in the first place, and
so far you have not captured the distinction Derek was asking about.

>Using this definition the email example is local and both bind examples
>are remote.
... and any definition that classifies the e-mail example as "local" is
just broken.

Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Director of Software Engineering, Novell http://novell.com

[Black, Michael]

You might try re-using the rather large effort that went into the CERT
taxonomy:
http://www.cert.org/research/taxonomy_988667.pdf

You'll note the complete lack of "local" and "remote" in the taxonomy.

The email example of "rm -r /*" being executed would be:
Attack:
Tool: Information Exchange
Vulnerability: Design
Action: Delete
Target: Data
Unauthorized Result: Corruption of Information

Remote exploit of Bind (causing "rm -r /*" to be executed):
Attack:
Tool: User Command
Vulnerability: Design
Action: Delete
Target: Data
Unauthorized Result: Corruption of Information=09

Remote exploit of Bind (causing a shell to be opened):
Attack:
Tool: User Command
Vulnerability: Design
Action: Bypass
Target: Account
Unauthorized Result: Increased Access


If you really want to stick with "remote" and "local" I think you can
define them thusly:
Remote -- control/access of resources occurs from outside the
machine/network
Local -- control/access of resources occurs on the local machine (i.e.
no network connection required)

Using this definition the email example is local and both bind examples
are remote. The bind vulnerabilities are completely solved by
unplugging the machines from the network whereas the email machine may
still be vulnerable after being disconnected.

=09
_______________________________
Michael D. Black, MSIA, CISSP, IAM
Information Systems Security Officer
Essex Corporation
black@essexcorp.com
-----Original Message-----
From: Crispin Cowan [mailto:crispin@novell.com]=20
Sent: Sunday, July 17, 2005 4:59 AM
To: James Longstreet
Cc: Derek Martin; bugtraq@securityfocus.com
Subject: Re: On classifying attacks

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=20
> unless a local user runs an executable. The only thing it exploits=20
> is trust of email (or similar vector).
But it is a remote *attack*. There is no other word for it than "remote"
when the attacker is not local.

Which is not to say that the distinction Derek raised is invalid; there
certainly is a semantic difference between an attack delivered by an
e-mail, which does nothing until the user reads it or clicks on
something, and a traditional remote attack where the attacker exploits a
flaw in a program that is listening. Such a program typically is a
server (BIND, Apache, Sendmail) but could also be a client (Gaim).
Pushing the boundaries, the program could be a web browser, where the
attack does happen immediately, does not involve a Trojan, but does
still require the user to do something like click a particular URL.

So what we have is a very complicated space full of adjectives:

* Attack: doing bad stuff to someone else's stuff.
* Vulnerability: an unfortunate software flaw or configuration that
enables an attack. It might be very specific, such as a buffer
overflow vulnerability in a particular program, or it might be
very general, such as "running Outlook with administrator
privilege".
* Exploit: software that automates attacking a vulnerability.
o *Note:* by this definition, an e-mail virus that leverages
the common fact that many users run Outlook as administrator
is in fact an "exploit", even if it is a weak one.
* Remote: attacker is over there somewhere, usually across some kind
of network.
* Local: attacker and victim are connected to the same computer.
o *Note:* in common parlance, this usually means that the
attacker must compose a local vulnerability with some other
vulnerability that will get them a login shell on the
machine to be attacked, or must be granted legitimate access
to the machine.

These terms are all commonly used in Bugtraq discussions, and I believe
these definitions follow common usage. Using these terms precisely is
important.

Yet none of them capture the distinction Derek pointed out, and so
perhaps we need a new term. We could say that attacks against connected
programs like BIND and Gaim are "synchronous" and attacks that involve
sending now for impact later such as e-mailed malware are
"asynchronous".

Crispin
--=20
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Director of Software Engineering, Novell http://novell.com

[Technica Forensis]

> >Using this definition the email example is local and both bind examples
> >are remote.
> .. and any definition that classifies the e-mail example as "local" is
> just broken.

This really depends on the situation. Say I write an exploit that
when run as a user spawns a listening ssh service with root priv. I
get on the system however I do, download this file and exec it. I
think everyone would agree that is a local exploit.
I send that same file as an email attachment to some dolt and peer
pressure him into running it. Just because I downloaded the file by
emailing it to said dolt doesn't change the exploit from local to
remote. It potentially changes it from 'exploit' to trojan, but it is
still being executed locally.

And, I agree with Crispin that the local/remote distinction is a huge
gaping hole in the taxonomy, but rather than not using it I think it
should be added to and improved on.

C

[Black, Michael]

Perhaps the current popularity of remote/local terms comes from the
Lincoln Labs studies done in 1998:
http://www.usenix.org/events/sec99/full_papers/ghosh/ghosh_html/

Attacks were divided into four categories:
denial of service
probing/surveillance
remote to local
user to root attacks

In the email examples given so far (note that nothing of similarity was
in the LL study) they would all be "remote to local".
There's no need for trying to define a compound attack -- it serves no
purpose. Plus the confusion that results from using just "remote" or
"local" should be more than obvious to anybody reading this thread.

If you don't want to use a formal taxonomy for talking about these
things you will always suffer from misunderstanding. Dr Cowan makes
this point below -- he apparently calls the email portion "local" and
the social engineering "remote".

I believe the original intent of the two "remote to local" and "user to
root" classes was to distinguish the threat level. "user to root"
implies that you only need worry about those people who have physical
access to the target, and "remote to local" meant you had to worry about
the millions of users on the internet. Then end result being you
worried a heck of a lot more about "remote to local" than "user to root"
(although both provide root access).
_______________________________
Michael D. Black, MSIA, CISSP, IAM
Information Systems Security Officer
Essex Corporation
black@essexcorp.com

-----Original Message-----
From: Crispin Cowan [mailto:crispin@novell.com]=20
Sent: Sunday, July 24, 2005 7:47 AM
To: Technica Forensis
Cc: Black, Michael; James Longstreet; Derek Martin;
bugtraq@securityfocus.com
Subject: Re: On classifying attacks

Technica Forensis wrote:
> This really depends on the situation. Say I write an exploit that
> when run as a user spawns a listening ssh service with root priv. I
> get on the system however I do, download this file and exec it. I
> think everyone would agree that is a local exploit.
> I send that same file as an email attachment to some dolt and peer
> pressure him into running it. Just because I downloaded the file by
> emailing it to said dolt doesn't change the exploit from local to
> remote. It potentially changes it from 'exploit' to trojan, but it is
> still being executed locally.
> =20
That sounds like a compound attack with 2 stages:

* a social engineering attack to get the victim to run the code
o can be very simple like "please run this code"
o can be very sophisticated, like phishing attacks carefully
crafted to resemble legitimate mail to get the user to click
on something
* a local attack that happens when you run the malware

What makes this compound attack "remote" is that the social engineering
attack is remote.

This makes most common viruses compound remote/local attacks with a
remote social engineering attack to somehow induce the user to run a
local attack. The exception to this is e-mail viruses that require no
social engineering because they can exploit some flaw in the preview
pane or such like so that the user only has to browse the mail to run
the malware.

Crispin
--=20
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Director of Software Engineering, Novell http://novell.com

[Crispin Cowan]

Technica Forensis wrote:
> This really depends on the situation. Say I write an exploit that
> when run as a user spawns a listening ssh service with root priv. I
> get on the system however I do, download this file and exec it. I
> think everyone would agree that is a local exploit.
> I send that same file as an email attachment to some dolt and peer
> pressure him into running it. Just because I downloaded the file by
> emailing it to said dolt doesn't change the exploit from local to
> remote. It potentially changes it from 'exploit' to trojan, but it is
> still being executed locally.
>
That sounds like a compound attack with 2 stages:

* a social engineering attack to get the victim to run the code
o can be very simple like "please run this code"
o can be very sophisticated, like phishing attacks carefully
crafted to resemble legitimate mail to get the user to click
on something
* a local attack that happens when you run the malware

What makes this compound attack "remote" is that the social engineering
attack is remote.

This makes most common viruses compound remote/local attacks with a
remote social engineering attack to somehow induce the user to run a
local attack. The exception to this is e-mail viruses that require no
social engineering because they can exploit some flaw in the preview
pane or such like so that the user only has to browse the mail to run
the malware.

Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Director of Software Engineering, Novell http://novell.com

[Crispin Cowan]

Black, Michael wrote:
> Perhaps the current popularity of remote/local terms comes from the
> Lincoln Labs studies done in 1998:
> http://www.usenix.org/events/sec99/full_papers/ghosh/ghosh_html/
>
> Attacks were divided into four categories:
> denial of service
> probing/surveillance
> remote to local
> user to root attacks
>
I participated in that Lincoln Labs study, and my recollection is that
the remote/local distinction was already popular on bugtraq at the time.
The LL study was an attempt to simulate a natural threat.

> In the email examples given so far (note that nothing of similarity was
> in the LL study) they would all be "remote to local".
>
Well, no. There is also direct "remote to root", which is a significant
classification that is distinct from "remote to local" and "local to
root". It is what you get if you have an exploit against root privileged
daemons (BIND, ntpd, etc.) and what you get if you have an exploit
against Microsoft Outlook being run as Administrator.

> There's no need for trying to define a compound attack -- it serves no
> purpose.
How is that? Classification schemes work best when you break things down
to their component atoms so that you can build up letters into words and
words into sentences. Those pesky attackers insist on using blended
attacks, and if we want to discuss what attackers do, we will either
need to define compound attacks, or else come up with a *very* large
lexicon :)

Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering, Novell http://novell.com

[Forte Systems - Iosif Peterfi]

Ok, so let's split them like this:

1. Simple
1.1 Remote
1.2 Local
2. Compound
2.1 Social engineered
2.2 Technical
2.3 Local


remote with no victim intervention - "Simple remote attack"

logged with a valid local account(shell access) , no victim intervention (no
remote attack involved) - "Simple local attack".

remote with victim intervention - "Compound social engineered attacks", also
called "Stupid attack" :D

remote with tiny victim intervention (like reading the e-mail body, without
running any script/executable) to trigger the attack - "Compound technical
attack".

logged with a valid local account (shell access) , with victim intervention
- "Compound local attack".


Uhm.. suppose somebody attacks a webserver with a remote exploit. If is
succesful, in the "worst" case he gets a shell of the httpd user. Then he
uses a vulnerability in the kernel to obtain root priviledge. The attacks
are one simple remote and one simple local.

If say .. the kernel vuln needed restart .. and the victim(not the hacker)
restarts the server... that makes the attacks .. one simple remote and one
"compound local attack".

Basicaly, compound attacks need the victim intervention. If the victim is
the same person as the hacker.. there is only simple attacks :D. But there's
allways two people involved. If the victim does anything to make the attack
possible.. even touching one key .. that attack is compound.

Let's see .. if you download and execute a trojaned sshd binary and execute
it .. is compound because .. err .. you're the victim. If you download it
and execute it on your friend's computer ... is simple .. because he didn't
do anything to make the attack possible...

If you e-mail it to your friend - and type in the body : "DO NOT OPEN THIS
IS A VIRUS!" - is "compound social engeneered". If you craft a special email
which exploits outlook and runs it, is "compound technical".

Phtiu !
Does this makes sense to anyone ?!




-----Original Message-----
From: Crispin Cowan [mailto:crispin@novell.com]
Sent: Sunday, July 24, 2005 2:47 PM
To: Technica Forensis
Cc: Black, Michael; James Longstreet; Derek Martin;
bugtraq@securityfocus.com
Subject: Re: On classifying attacks

Technica Forensis wrote:
> This really depends on the situation. Say I write an exploit that
> when run as a user spawns a listening ssh service with root priv. I
> get on the system however I do, download this file and exec it. I
> think everyone would agree that is a local exploit.
> I send that same file as an email attachment to some dolt and peer
> pressure him into running it. Just because I downloaded the file by
> emailing it to said dolt doesn't change the exploit from local to
> remote. It potentially changes it from 'exploit' to trojan, but it is
> still being executed locally.
>
That sounds like a compound attack with 2 stages:

* a social engineering attack to get the victim to run the code
o can be very simple like "please run this code"
o can be very sophisticated, like phishing attacks carefully
crafted to resemble legitimate mail to get the user to click
on something
* a local attack that happens when you run the malware

What makes this compound attack "remote" is that the social engineering
attack is remote.

This makes most common viruses compound remote/local attacks with a
remote social engineering attack to somehow induce the user to run a
local attack. The exception to this is e-mail viruses that require no
social engineering because they can exploit some flaw in the preview
pane or such like so that the user only has to browse the mail to run
the malware.

Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Director of Software Engineering, Novell http://novell.com



--
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/





--
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/

[Daniel Weber]

Crispin Cowan wrote:
> I participated in that Lincoln Labs study, and my recollection is
> that the remote/local distinction was already popular on bugtraq at
> the time.

I was working on that project, and Dr. Cowan's recollection matches
mine. Talks of "local" and "remote" were already in use somewhat on
Bugtraq, although I don't think they had yet become universal. (I'd
like to claim that the Lincoln studies helped push use of those terms
along, but the concepts are so simple and elegant that their universal
use was inevitable.)

One of the mental models involved in those 1998 classifications of
attacks was a "presence" of an attacker -- is the attacker outside
your network, on your network, or on your machine as a non-privileged
user? This model doesn't necessarily fit in well with some of today's
most common attacks, as was mentioned when this thread started.

It's not that trojan horses (whether you interpret that to mean just
hostile applications, or hostile data run by vulnerable applications)
weren't known about in 1998. It's that those attacks weren't
considered all that important when compared to things that were more
common at the time -- smurf attacks, pings of death, Sendmail buffer
overflows, SYN queue starvation.



I've seen a lot of classification schemes proposed on Bugtraq in the
intervening years, some of them quite good. (Search the archives for
"taxonomy" or "classification".) But unless they are -very- simple to
use, they won't be taken up by the community. If you can come up with
a single word that imputes the concept of "malicious data that I can
easily get onto the victim's machine and in front of the victim's
eyes but requires him to run it," that would be a great step forward.

Simplicity is key. (Unlike this posting, which I did not have time
to make shorter and simpler.)

[Tim Nelson]

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--0-1121698524-1122949727=:3636
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <Pine.LNX.4.60.0508021236041.3636@tnelson.webalive. biz>

On Fri, 29 Jul 2005, Forte Systems - Iosif Peterfi wrote:

> Ok, so let's split them like this:
>
> 1. Simple
> 1.1 Remote
> 1.2 Local
> 2. Compound
> 2.1 Social engineered
> 2.2 Technical
> 2.3 Local

I prefer something just as simple, but maybe more flexible:
1. Interaction level
i) Automatic (no victim action required)
ii) Semi-Automatic (victim performs some normally safe action,
ie. opening e-mail, or a cron job runs)
iii) Manual (victim is socially engineered into performing
su -c 'rm -rf /' or some such stupid thing)
2. Target
i) Access
ii) Elevation (Privilege elevation)

For all attacks, select one item from section 1, and one from
section 2.

Traditional remote attacks are Automatic Access attacks.
Traditional local attacks are Automatic Elevation attacks. E-mail trojans
are Semi-Automatic or Manual Access attacks.

Daniel Weber wrote:
> I've seen a lot of classification schemes proposed on Bugtraq in the
> intervening years, some of them quite good. (Search the archives for
> "taxonomy" or "classification".) But unless they are -very- simple to
> use, they won't be taken up by the community. If you can come up with
> a single word that imputes the concept of "malicious data that I can
> easily get onto the victim's machine and in front of the victim's
> eyes but requires him to run it," that would be a great step forward.

Hmm. Methinks I need to use more hyphens; Semi-Automatic-Access
attack :).

HTH,

--
Kind Regards,

Tim Nelson
Server Administrator

P: 03 9934 0888
F: 03 9934 0899
E: tim.nelson@webalive.biz
W: www.webalive.biz

WebAlive Technologies
Level 1, Innovation Building
Digital Harbour
1010 La Trobe Street
Docklands Melbourne VIC 3008

This email (including all attachments) is intended solely for the named addressee. It is confidential and may contain legally privileged information. If
you receive it in error, please let us know by reply email, delete it from your system and destroy any copies. This email is also subject to copyright. No
part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner.

Emails may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems. We give no
warranties in relation to these matters. If you have any doubts about the authenticity of an email purportedly sent by us, please contact us immediately.
--0-1121698524-1122949727=:3636--

[Crispin Cowan]

Forte Systems - Iosif Peterfi wrote:
> Basicaly, compound attacks need the victim intervention.
No; compound attacks need more than one attack vector. In your example
of attacking a web server, the attacker needs a compound attack
comprised of a remote->local attack and a local->root attack to take
over the machine. It is "compound" in that it is comprised of more than
one attack, but does not necessarily involve the victim's intervention.

Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering, Novell http://novell.com

[Thierry Carrez]

Forte Systems - Iosif Peterfi wrote:

> Ok, so let's split them like this:
>
> 1. Simple
> 1.1 Remote
> 1.2 Local
> 2. Compound
> 2.1 Social engineered
> 2.2 Technical
> 2.3 Local
>
> [...]
> Does this makes sense to anyone ?!

I use "Active" instead of "Simple" and "Passive" instead of "Compound",
but it's globally the same. "Compound"/"Passive" require the attacker to
wait for something else to happen. That leaves me with:

Remote Active
Local Active
Remote Passive (Social engineered)
Remote Passive (Technical)
Local Passive

--
Koon

[Shwaine]

On Thu, 28 Jul 2005, Daniel Weber wrote:

> I've seen a lot of classification schemes proposed on Bugtraq in the
> intervening years, some of them quite good. (Search the archives for
> "taxonomy" or "classification".) But unless they are -very- simple to
> use, they won't be taken up by the community. If you can come up with
> a single word that imputes the concept of "malicious data that I can
> easily get onto the victim's machine and in front of the victim's
> eyes but requires him to run it," that would be a great step forward.
>
> Simplicity is key. (Unlike this posting, which I did not have time
> to make shorter and simpler.)
>

(Apologies for the late reply, I've only just caught up on this thread)

Would that it were that simple. Then there would not be debates. You've
somewhat captured the intuitive idea with your long phrase, that being
that these exploits require user intervention of some fashion to succeed.
Were I to take a real world phrase and apply it to the cyber realm, the
closest that comes to mind is "booby trap", but this does not lend itself
well to conveying the consequences of triggering a trap. Nor do I like
applying classifications such as "remote to user" to exploits involving
user interaction, as this phrase does not distinguish between automated
attacks and those requiring user intervention, even though it does convey
some of the requirements and consequences of the attack.

Realistically, these types of attacks encompass multiple components such
as the delivery vector (e.g. webpage, email), level of user interaction
(e.g. regular use of program, clicking attachment) and consequences (e.g.
privileges obtained). A simple classification scheme along the lines of
"remote to root" is not well suited to conveying all these details. From a
modeling standpoint, breaking the attacks down into its components makes
sense, but that is not always as useful from a user standpoint. The user
might be more concerned about distinguishing exploits that can occur
during normal use from those which require more social engineering as the
former implies little to no user control over the risks (other than
patching when a patch is available of course). Academically however, these
might just be two branches rather far down on a taxonomy tree. So, I
suppose it has to be asked if we just want catchy phrases to impress upon
the user the severity of an issue so they patch or if we want an academic
classification scheme. The two aims do not always align.

Melissa

[Forte Systems - Iosif Peterfi]

Well, yes. Interaction level is the key in the classification.
Wonder if the community will make use of it.

Iosif Peterfi
Network Administrator
S.C. Forte Systems SRL
http://www.fortesys.ro/


-----Original Message-----
From: Tim Nelson =5Bmailto:tim.nelson=40webalive.biz=5D
Sent: Tuesday, August 02, 2005 5:46 AM
To: Forte Systems - Iosif Peterfi
Cc: 'Crispin Cowan'; 'Technica Forensis'; 'Black, Michael'; 'James
Longstreet'; 'Derek Martin'; bugtraq=40securityfocus.com
Subject: RE: On classifying attacks

On Fri, 29 Jul 2005, Forte Systems - Iosif Peterfi wrote:

> Ok, so let's split them like this:
>
> 1. Simple
> 1.1 Remote
> 1.2 Local
> 2. Compound
> 2.1 Social engineered
> 2.2 Technical
> 2.3 Local

I prefer something just as simple, but maybe more flexible:
1. Interaction level
i) Automatic (no victim action required)
ii) Semi-Automatic (victim performs some normally safe action,
ie. opening e-mail, or a cron job runs)
iii) Manual (victim is socially engineered into performing
su -c 'rm -rf /' or some such stupid thing)
2. Target
i) Access
ii) Elevation (Privilege elevation)

For all attacks, select one item from section 1, and one from
section 2.

Traditional remote attacks are Automatic Access attacks.
Traditional local attacks are Automatic Elevation attacks. E-mail trojans
are Semi-Automatic or Manual Access attacks.

Daniel Weber wrote:
> I've seen a lot of classification schemes proposed on Bugtraq in the
> intervening years, some of them quite good. (Search the archives for
> =22taxonomy=22 or =22classification=22.) But unless they are -very- simpl=
e to
> use, they won't be taken up by the community. If you can come up with
> a single word that imputes the concept of =22malicious data that I can
> easily get onto the victim's machine and in front of the victim's
> eyes but requires him to run it,=22 that would be a great step forward.

Hmm. Methinks I need to use more hyphens; Semi-Automatic-Access
attack :).

HTH,

--
Kind Regards,
=A0
Tim Nelson
Server Administrator
=A0
P: 03 9934 0888
F: 03 9934 0899
E: tim.nelson=40webalive.biz
W: www.webalive.biz
=A0
WebAlive Technologies
Level 1, Innovation Building
Digital Harbour
1010 La Trobe Street
Docklands Melbourne VIC 3008

This email (including all attachments) is intended solely for the named
addressee. It is confidential and may contain legally privileged
information. If
you receive it in error, please let us know by reply email, delete it from
your system and destroy any copies. This email is also subject to copyright.=

No
part of it should be reproduced, adapted or transmitted without the written
consent of the copyright owner.

Emails may be interfered with, may contain computer viruses or other defects=

and may not be successfully replicated on other systems. We give no
warranties in relation to these matters. If you have any doubts about the
authenticity of an email purportedly sent by us, please contact us
immediately.




--
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/

[Duncan Simpson]

Nobody has brought this up, so perhaps I should. The problem most
clasiffication schemes discussed are hitting is that security holes are
transitive: remote arbitary code execution+local root exploit=remote root
exploit.

If the exploit code is running on your box then any exploits it peforms are
probably local, even if the attack code is launched by a remote exploit. A
description of a beast as composition of seperate remote and local exploits
would allow a simple remote/local distinction to apply (where "local" means
requiring the code to executed on the attacked box).

Whether trojans count as exploits per se or not is harder--most trojans and
other malware involve authorised users explicitly running a program and that
program doing authorised things. The activity being undesirable activity the
victim did not intend does not change that fact.

As far "malicious data that the victim must explicitly execute" I think such a
word already exists: malware (or trojan, if the appropriate disguise applies).
The success rate of persuading users to run such code is distressingly high.
--
Duncan (-:
"software industry, the: unique industry where selling substandard goods is
legal and you can charge extra for fixing the problems."