full-disclosure - Multiple Vendor Anti-Virus Software DetectionEvasion Vulnerability through forged magic byte

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri Oct 28 12:47:55 2005
From: gautam.bipin at gmail.com (Bipin Gautam)
Subject: Multiple Vendor Anti-Virus Software
	DetectionEvasion Vulnerability through forged magic byte

> Consequently, the issue that you describe is *not* a
> vulnerability issue, but rather just an example of a new variant
> that has not yet been added to an AV vendor's database of "known
> viruses".
>

yap, maybe* but i consider this issue equv. to the 'classic issue' of
adding NOP to the shell-code to bypass IDS/IPS You ain't gonna add
every possible combinations as signatures!


>Instead of beahviour analysis, most AV vendors choose uterly stupid
>PE section fingerprints, defeated by adding a few bytes. Go figure. of
>course this is no vulnerability, it's a feature!

Is, CA eTrust Antivirus, run in Reviewer mode by default?
(sorry, i haven't tryed ant Av lately)

-------------
>My theory on this is simple :
>- ALL files can't be analysed the same way by
>AV engines (due to speed issues) (In other
>words not all analysis/fingerpritns is applied to
>every file)

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


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

Variant huh?

	My defination of variant are bit straight forward. And sure isn't a
'universal trick' that can be used to modified any malicious
executable (which has known Av signature)  by a 8 year old with 0
programming knowledge or by using any special tools to make it
un-detectable, later. Admit it... Av vendors aren't going to
doyuble/tripple their Av defination to detect all of such possible
varient.
Common, is the execution point of ANY instruction code or program flow
is being changed?

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

Lastly, yap I also feel there are 2 type of ppl. in the world. One who
gives answers to a question and the other who askz another another
question AS the answer of the previous question.


-best regards,
Bipin Gautam

Zeroth law of security: The possibility of poking a system from lower
privilege is zero unless & until there is possibility of direct,
indirect or consequential communication between the two...