[Full-disclosure] Re: Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability through forged magic byte

From: x (x_at_blackopssec.com)
Date: 10/28/05

  • Next message: Martin Schulze: "[Full-disclosure] [SECURITY] [DSA 877-1] New gnump3d packages fix several vulnerabilities" 
    To: full-disclosure@lists.grok.org.uk
Date: Fri, 28 Oct 2005 00:05:33 -0600

    Andrey Bayora said:
    + > If your altered virus sample
    + > still executes correctly, you have simply created a new
    + > virus variant.
    +
    + Not exactly, please look at this virustotal.com log
    + http://www.securityelf.org/updmagic.html
    +
    + The altered (120 bytes prepended) TXT_* variant is STILL
    + detected by your product (CA), but when I change the first
    + byte from "Z" to "M" - your product fails (MZ_* variant).
    + I believe, that if I PREPEND 120 bytes to known virus and
    + the virus is still detected with the SAME signature -
    + then I DID NOT create a new variant. Now one more example:
    + try to change the first byte "Z" in the TXT_* variant to
    + any value, but not to "M" - this virus will be detected,
    + but when you change to "M", thus creating the .EXE magic
    + byte - the variant is not detected !!! My conclusion:
    + the antivirus “thought” that the file is the executable
    + type instead of determining the file type by the
    + extension.
    +
    + That is my point, if you still think that your product is
    + OK - do not do anything.

    Thierry Zoller said:
    + WJK> You are effectively altering existing viruses to the
    + WJK> point that AV scanners do not detect them.
    +
    + No, he is changing a few bytes only.
    +
    + WJK> If your altered virus sample still executes
    + WJK> correctly, you have simply created a new virus
    + WJK> variant.
    +
    + No, there is no variant, the virus executes EXACTLY as
    + before. A variant acts differenlty then a precedent
    + version, else it would be no variant. To your AV engine it
    + is a variant, yes, but only because it is flawed.

    Why are you guys having such a difficult time comprehending
    this? Read both the general and AV-specific definitions of
    the word "variant".

    http://dictionary.reference.com/search?q=variant
    http://www.symantec.com/avcenter/glossary/index.html#v
    http://us.mcafee.com/VirusInfo/VIL/glossary_app.asp#v

    If you take an existing virus and modify it, you have
    created a variant.

    The AV vendors aren't going to patch their products if they
    don't detect your PoC; they're just going to write a new
    signature or modify an existing signature to detect your
    new variants. The fact that it can and will be fixed by
    AV signatures instead of product patches should help you
    figure out if this is a product vulnerability issue or just
    a "new virus variant" issue.

    BTW, Andrey, did you bother to use the "deep scan",
    "heuristic mode", "reviewer mode", etc to see if any
    of those AV scanners picked up your new variants? I bet
    you didn't.

    Thierry Zoller said:
    + WJK> Consequently, the issue that you describe is *not* a
    + WJK> vulnerability issue, but rather just an example of a
    + WJK> new variant that has not yet been added to an AV
    + WJK> vendor's database of "known viruses".
    +
    + Thank you James, this _to my knowledge_ (perhaps the guy
    + from vmyths knows better) is the first time the complete
    + failure of todays AV solutions is shown naked publicaly
    + directly by a representant of an AV company. This
    + statement coming from a AV vendor is simply exposing what
    + is known in the sec. community since many years.

    To say that an AV scanner is a "complete failure" because it
    fails to detect a variant you just created is inane. Each
    of the top 10 AV scanners detects well over 95% of all known
    viruses. The AV scanners aren't perfect, but they
    definitely make a BIG BIG difference wrt malware risk
    mitigation.

    ftp://agn-www.informatik.uni-hamburg.de/pub/texts/tests/pc-av/2003-04/0xecsum.txt

    Thierry Zoller said:
    + The solution was to make the engines a bit "smarter", i.e
    + analyse the header to determine the type and then ONLY
    + apply the signatures/heuristics which apply to the type of
    + the file (i am not speaking about the extension of the
    + file here) thus speeding up the process. Changing the
    + header just makes the smart engines look...well... a bit
    + dumb in my regards.

    There are two types of people in the world: those who
    complain about problems, and those who find solutions to
    problems. Where's your superior AV scanner? 

    --
x @ bos
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
  • Next message: Martin Schulze: "[Full-disclosure] [SECURITY] [DSA 877-1] New gnump3d packages fix several vulnerabilities"

    Relevant Pages