Re: Polymorphic Shellcode detection

From: Robert Graham (robert_david_graham_at_yahoo.com)
Date: 05/12/03

  • Next message: David Markle: "RE: dragon and snort logs" 
    Date: Mon, 12 May 2003 10:24:49 -0700 (PDT)
To: sam stover <sstover@enterasys.com>, zheng@intruvert.com, focus-ids@securityfocus.com

    --- sam stover <sstover@enterasys.com> wrote:
    > Another way is to check for the number of binary bytes.
    > ISS does this and it's obsolete for some other (potentially valid) reasons.

    Please don't blindly repeat the untruths published by Intruvert. I have read
    Intruvert's marketing material against ISS, most of it is untrue. Moreover,
    comparing their marketing material to other ISS competitors, I would
    characterize them as the "most untrue".

    The way ISS does "signatures" is through "protocol-analysis". For example, the
    following is the signature that detected the SQL Slammer worm:

     SQL_SSRP_StackBo is (
        udp.dst == 1434
        ssrp.type == 4
        ssrp.name.length > ssrp.threshold)
     where ssrp.type is first-byte of packet
     where ssrp.name is nul-terminated string starting at second byte
     where ssrp.threshold defaults to 97

    We decode Microsoft's SSRP protocol, then test it for conditions. Specifically,
    we test it against the "vulnerability". This is why we've been successful at
    detecting new attacks before the exploits are known: we don't have to wait
    until exploits appear to write signatures, but can instead test against the
    vulnerability itself. This signature was written 5 months before Slammer
    appeared.

    Notice that nowhere in the "SQL_SSRP_StackBo" is there a count of the number of
    binary characters. Moreover, you could easily inject more than 97 bytes of
    ASCII data in this field and see that we still trigger -- proof enough that we
    aren't counting binary characters. You can use my tool at
    <http://www.robertgraham.com/tools/scanslam/> to easily do this.

    Note that ISS does have a couple of "heuristics" that look for common aspects
    of known exploits hoping to catch a 0day attack. One does indeed count the
    number of binary characters found in POST data. These heuristics are easily
    evaded -- we don't use them for normal signatures. For example, one of the
    "lamest" and most easily evaded of these is HTTP_RepeatedChar: this simply
    counts repeated characters in URLs. This is even easier to evade than changing
    opcodes to ASCII text. On the other hand, it caught the recent IIS WebDav 0day
    attack at customer sites. As soon as we knew about the IIS WebDav
    vulnerability, we immediately created a signature for it. As I said, we don't
    depend upon these heuristics for real signatures: while they have proven useful
    in catching unknown exploits, they are pretty easy to evade.

    __________________________________
    Do you Yahoo!?
    The New Yahoo! Search - Faster. Easier. Bingo.
    http://search.yahoo.com

    -------------------------------------------------------------------------------
    INTRUSION PREVENTION: READY FOR PRIME TIME?

    IntruShield now offers unprecedented Intrusion IntelligenceTM capabilities
    - including intrusion identification, relevancy, direction, impact and analysis
    - enabling a path to prevention.

    Download the latest white paper "Intrusion Prevention: Myths, Challenges, and Requirements" at:
    http://www.securityfocus.com/IntruVert-focus-ids2
    -------------------------------------------------------------------------------

  • Next message: David Markle: "RE: dragon and snort logs"
    • Quantcast