On classifying attacks Jul 15 2005 02:39AM
Derek Martin (code pizzashack org) (3 replies)
Re: On classifying attacks Jul 15 2005 11:40PM
James Longstreet (jlongs2 uic edu)
Re: On classifying attacks Jul 15 2005 11:22PM
Indigo Haze (hazer chipshot net)
RE: On classifying attacks Jul 15 2005 03:58PM
Bryan McAninch (bryan mcaninch org)

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



-----Original Message-----
From: Derek Martin [mailto:code (at) pizzashack (dot) org [email concealed]]
Sent: Thursday, July 14, 2005 09:40 PM
To: bugtraq (at) securityfocus (dot) com [email concealed]
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
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
GPG Key ID: 0x81CFE75D

[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus