lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Jul 2005 10:58:47 -0500
From: "Bryan McAninch" <bryan@...ninch.org>
To: <bugtraq@...urityfocus.com>
Subject: RE: On classifying attacks



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@...zashack.org] 
Sent: Thursday, July 14, 2005 09:40 PM
To: bugtraq@...urityfocus.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





Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ