On classifying attacks

From: Derek Martin (code_at_pizzashack.org)
Date: 07/15/05

  • Next message: Bryan McAninch: "RE: On classifying attacks" 
    Date: Thu, 14 Jul 2005 22:39:30 -0400
To: bugtraq@securityfocus.com

    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

    • application/pgp-signature attachment: stored
  • Next message: Bryan McAninch: "RE: On classifying attacks"

    Relevant Pages

    • SecurityFocus Microsoft Newsletter #260
      ... MICROSOFT VULNERABILITY SUMMARY ... Remote: Yes ... attacker to execute arbitrary code on a vulnerable computer with SYSTEM ...
      (Focus-Microsoft)
    • SecurityFocus Microsoft Newsletter #255
      ... MICROSOFT VULNERABILITY SUMMARY ... FUDforum is prone to a remote arbitrary PHP file upload vulnerability. ... A local attacker can subsequently access the file and disclose authentication ...
      (Focus-Microsoft)
    • SecurityFocus Microsoft Newsletter #256
      ... MICROSOFT VULNERABILITY SUMMARY ... Remote: Yes ... An attacker may exploit this vulnerability to gain unauthorized remote access ...
      (Focus-Microsoft)
    • SecurityFocus Microsoft Newsletter #259
      ... MICROSOFT VULNERABILITY SUMMARY ... FL Studio FLP File Processing Heap Overflow Vulnerability 4. ... wzdftpd is affected by a remote arbitrary command execution vulnerability. ... allowing a remote attacker to supply format specifiers ...
      (Focus-Microsoft)
    • SecurityFocus Microsoft Newsletter #249
      ... MICROSOFT VULNERABILITY SUMMARY ... Remote: Yes ... This issue will facilitate remote exploitation as an attacker may distribute ...
      (Focus-Microsoft)