Re: On classifying attacks

From: Indigo Haze (hazer_at_chipshot.net)
Date: 07/16/05

  • Next message: James Longstreet: "Re: On classifying attacks"
    Date: Fri, 15 Jul 2005 18:22:09 -0500
    To: bugtraq@securityfocus.com
    
    

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


  • Next message: James Longstreet: "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)