On classifying attacks

Perhaps the current popularity of remote/local terms comes from the
Lincoln Labs studies done in 1998:
http://www.usenix.org/events/sec99/f...sh/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

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

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/f...sh/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

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/

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

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

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

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

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

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/

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