Re: On Polymorphic Evasion

From: Marius Huse Jacobsen (mahuja_at_c2i.net)
Date: 10/21/04

  • Next message: Siles, Raul: "The results of the last Honeynet SotM 32 have been published" 
    Date: Thu, 21 Oct 2004 00:03:17 +0200
To: focus-ids@securityfocus.com

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Hello Phantasmal,

    Saturday, October 2, 2004, 2:28:01 AM, you wrote:

    PP> On Polymorphic Evasion
    PP> by Phantasmal Phantasmagoria
    PP> phantasmal@hush.ai

    PP> What is important, at least to me, is the continual flow of ideas.
    PP> As I see it, releasing this paper is an investment in future ideas
    PP> from which I myself (and perhaps others in the world) may benefit.

    Your approach tries to "gather" all execution paths into a big vein
    leading to the heart, which is not necessary. I've encountered pieces
    of code that disassembled successfully nearly whichever entry spot you
    chose, though in those examples the circumstances (register settings
    etc) would be life or death for each path. Note however, that these
    were not designed for it, and if someone spends the time to carefully
    design such a piece of code, it will do the trick.

    Safe reads/writes will be quite possible, assuming that some register
    is set to some valid value. And since the stack pointer is most
    certainly valid...

    Second generation of that would be a generator, that generated such
    code from parameters of length and optionally a random seed.

    Your reference to the anti-virus fight against polymorphic detection
    is quite apt. To my knowledge several adapted execution emulation to
    unravel the polymorphic 'shell' around the virus itself, to enable
    signature detection. This came at a tradeoff of speed, but was
    effective, a lesson that should be noted by IDS writers.

    To properly detect nop sleds, it would then have to run the code,
    sandboxed or emulated, and of it ended up in the same 'end' state
    every time (each time at a different entry point) that would be the
    end of the nop sled which could then be flagged correctly. Add a
    little fuzz to detect sleds that has intentional failures (parent
    post's "jump args") for escaping detection, or cases of 'partial'
    sleds which doesn't cover the whole 'sled space' as one knows around
    where it will hit (filling the rest with garbage)

    However, running that on each bit of data passing the interface would
    demand computing resources beyond most. In this respect, filtering and
    only scanning data "foreign" to a protocol might help. For cases with
    exploits through datafiles, it might be worth passing the file data of
    those protocols to file analyzers, which then might feed data those
    find foreign into such a scanner.

    - --
    Best regards,
     Marius mailto:mahuja@c2i.net
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.5 (MingW32)

    iD8DBQFBYmFDl9nYJJam7WsRAlOkAKCscVp/PPshNiHhjSZ1fkvOvAEvNACfbsjt
    kRAhx60G5O9nYok5xMClBZ4=
    =up96
    -----END PGP SIGNATURE-----

    --------------------------------------------------------------------------
    Test Your IDS

    Is your IDS deployed correctly?
    Find out quickly and easily by testing it with real-world attacks from
    CORE IMPACT.
    Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
    to learn more.
    --------------------------------------------------------------------------

  • Next message: Siles, Raul: "The results of the last Honeynet SotM 32 have been published"