Onderwerp: Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability through

Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability through
forged magic byte.



AUTHOR: Andrey Bayora (www.securityelf.org)



For more details, screenshots and examples please read my article "The Magic
of magic byte" at www.securityelf.org . In addition, you will find a sample
"triple headed" program which has 3 different 'execution entry points',
depending on the extension of the file (exe, html or eml) - just change the
extension and the SAME file will be executed by (at least) THREE DIFFERENT
programs! (thanks to contributing author Wayne Langlois from
www.diamondcs.com.au).

DATE: October 25, 2005



VULNERABLE vendors and software (tested):



1. ArcaVir 2005 (engine 2005-06-03,vir def 2005-06-27, scanner ver
2005-03-06, package ver 2005-06-21)

2. AVG 7 (updates 24 June, ver.7.0.323, virus base 267.8.0/27)

3. eTrust CA (ver 7.0.1.4, engine 11.9.1, vir sig. 9229)

4. Dr.Web (v.4.32b, update 27.06.2005)

5. F-Prot (ver. 3.16c, update 6/24/2005)

6. Ikarus (latest demo version for DOS)

7. Kaspersky (update 24 June, ver. 5.0.372)

8. McAfee Internet Security Suite 7.1.5 (updates 25 June, ver 9.1.08,
engine 4.4.00, dat 4.0.4519 6/22/2005)

9. McAfee Corporate (updates 25 June, ver. 8.0.0 patch 10, vir def 4521,
engine 4400)

10. Norman ( ver 5.81, engine 5.83.02, update 2005/06/23)

11. TrendMicro PC-Cillin 2005 (ver 12.0.1244, engine 7.510.1002, pattern
2.701.00)

12. TrendMicro OfficeScan (ver7.0, engine 7.510.1002, vir pattern 2.701.00
6/23/2005)

13. Panda Titanium 2005 (updates 24 June, ver 4.02.01)

14. UNA - Ukrainian National Antivirus (ver. 1.83.2.16 kernel v.265)

15. Sophos 3.91 (engine 2.28.4, virData 3.91)



IMPORTANT NOTE:

Similar vulnerability may exist in many other antivirus\anti-spyware desktop
and gateway products. In addition, various "file filter" solutions may be
affected as well.



NOT VULNERABLE vendors and software (tested):



1. F-Secure (updates 24 June, ver 5.56 b.10450)

2. Avast (ver. 4.6.655, vir databas 0525-5 06/25/2005)

3. BitDefender (ver. 8.0.200, update 6/24/2005, engine 7.01934)

4. ClamWin (ver. 0.86.1, upd 24 June 2005)

5. NOD32 (updates 24 June, ver 2.50.25, vir database 1.1152)

6. Symantec Corporate (ver 10.0.0.359, engine 103.0.2.7)

7. Norton Internet Security 2005 (ver 11.5.6.14)

8. VBA32 (ver 3.10.4, updates 27.06.2005)

9. HBEDV Antivir Personal (ver 6.31.00.01, engine 6.31.0.7, vir def
6.31.0.109 6/24/2005)

10. Sophos 5 (ver. 5.0.2, vir def 3.93, upd 6/30/2005)

11. Sophos 3.95 (engine 2.30.4)



SEVERITY: critical



DESCRIPTION:



The problem exists in the scanning engine - in the routine that determines
the file type. If some file types (file types tested are .BAT, .HTML and
..EML) changed to have the MAGIC BYTE of the EXE files (MZ) at the beginning,
then many antivirus programs will be unable to detect the malicious file. It
will break the normal flow of the antivirus scanning and many existent and
future viruses will be undetected.



NOTE: In my test, I used the EXE headers (MZ), but it is possible to use
other headers (magic byte) that will lead to the same effect.



ANALYSIS:



Some file types like .bat, .html and .eml can be properly executed even if
they have some "unrelated" beginning. For example, in the case of .BAT
files - it is possible to prepend some "junk" data at the beginning of the
file without altering correct execution of the batch file. In my tests, I
used the calc.exe headers (first 120 bytes - middle of the dosstub section)
to change 5 different files of existing viruses. In addition, the simplest
test of this vulnerability is to prepend only the magic byte (MZ) to the
existing malicious file and check if this file is detected by antivirus
program.



NOTE, that this is NOT the case where the change of existing virus file
resulted in the "broken" detection signature (see details and the test logic
in "The Magic of magic byte" article at www.securityelf.org).



WORKAROUND:

I did not found any effective one besides of patching the vulnerable engine.



CREDITS:

The idea for this vulnerability came during discussions from Wayne Langlois
at diamondcs.com.au, who hinted that JPEGs could probably be exploited in
this way.



TIME LINE:



July 13, 2005 - Initial vendor notification

July 16, 2005 - Second vendor notification

......Waiting.....Waiting....

October 24, 2005 - Public disclosure (uncoordinated)

Hi Andreas Marx,

It is ironic that now the AV programs implemented the "smart" file format
checking, but "forgot" about file extensions
I think, that "smart" file format checking must be complemented with the
"smart" file extension checking.

Regards,
Andrey Bayora.


----- Original Message -----
From: "Andreas Marx" <gega-it@web.de>
To: "Andrey Bayora" <andrey@securityelf.org>; <bugtraq@securityfocus.com>
Sent: Wednesday, October 26, 2005 12:50 PM
Subject: Re: Multiple Vendor Anti-Virus Software Detection Evasion
Vulnerability through


>
> Hi!
>
> Thanks, that's interesting to read. In 2000, I've found and suggested the
following in an article I've written for the Virus Bulletin magazine
<http://www.virusbtn.com> :
>
> "[...] Some scanners do not actually scan all files even when set to "scan
all files" or when the mask "*.*" is used. Most of the time at least some
infected .BAT, .VBS and .COM files will be missed if they have non-standard
extensions. This happens when the scanner checks the file extension, not the
content, in order to scan solely for this kind of virus. It would be a good
idea for vendors to make a "smart" scan to find out the (hopefully) correct
file format. If there is more than one possibility (like ASCII text or a
..COM file), all possible supported formats should be scanned. [...]"
>
> You can find this (Title: "The Usual Suspects ? Part 1", Dec 2000) and
more related articles here:
> <http://www.av-test.org/sites/referen...s.php3?lang=en>
>
> cheers,
> Andreas Marx
> CEO, AV-Test.org
> <http://www.av-test.org>
>
>
> > Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability
through
> > forged magic byte.
>
> > AUTHOR: Andrey Bayora (www.securityelf.org)
>
> > For more details, screenshots and examples please read my article "The
Magic
> > of magic byte" at www.securityelf.org . In addition, you will find a
sample
> > "triple headed" program which has 3 different 'execution entry points',
> > depending on the extension of the file (exe, html or eml) - just change
the
> > extension and the SAME file will be executed by (at least) THREE
DIFFERENT
> > programs! (thanks to contributing author Wayne Langlois from
> > www.diamondcs.com.au).
>
> __________________________________________________ ____________
> Verschicken Sie romantische, coole und witzige Bilder per SMS!
> Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
>
>
>

Hi!

Thanks, that's interesting to read. In 2000, I've found and suggested the following in an article I've written for the Virus Bulletin magazine <http://www.virusbtn.com> :

"[...] Some scanners do not actually scan all files even when set to "scan all files" or when the mask "*.*" is used. Most of the time at least some infected .BAT, .VBS and .COM files will be missed if they have non-standard extensions. This happens when
the scanner checks the file extension, not the content, in order to scan solely for this kind of virus. It would be a good idea for vendors to make a "smart" scan to find out the (hopefully) correct file format. If there is more than one possibility (like
ASCII text or a .COM file), all possible supported formats should be scanned. [...]"

You can find this (Title: "The Usual Suspects ? Part 1", Dec 2000) and more related articles here:
<http://www.av-test.org/sites/referen...s.php3?lang=en>

cheers,
Andreas Marx
CEO, AV-Test.org
<http://www.av-test.org>


> Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability through
> forged magic byte.

> AUTHOR: Andrey Bayora (www.securityelf.org)

> For more details, screenshots and examples please read my article "The Magic
> of magic byte" at www.securityelf.org . In addition, you will find a sample
> "triple headed" program which has 3 different 'execution entry points',
> depending on the extension of the file (exe, html or eml) - just change the
> extension and the SAME file will be executed by (at least) THREE DIFFERENT
> programs! (thanks to contributing author Wayne Langlois from
> www.diamondcs.com.au).

__________________________________________________ ____________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

In message <019d01c5d96c$87e6ea80$0501a8c0@home>, Andrey Bayora
<andrey@securityelf.org> writes
>Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability through
>forged magic byte.

Interesting

Have you considered the possibility that some vendors at least may
include with each virus signature a set of file formats for which the
signature is valid, or just a flag to signify "all formats"?

If so, then the vendors will consider themselves not vulnerable, they
can simply update their virus definitions when and if variants with
different headers appear.

Even with 1:1 file format signatures, a vendor could presumable include
multiple virus definitions for one virus, one per file format, as
required

....

>For more details, screenshots and examples please read my article "The Magic
>of magic byte" at www.securityelf.org
....
--
Dave English Senior Software & Systems Engineer
Internet Platform Development, Thus plc

Hello Mark,

> vulnerability is limited in our products to one specific type of potential
> virus file
It is .bat files (if I remember).

>which is not commonly allowed in most IT systems
Yes, I think organizations must implement good e-mail policy that blocks all
executable file types (or allow some file types that needed for business and
block the rest).

>and needs to be executed manually
Maybe it is not always true if some virus drops locally .bat file and then
executes it.

I did not check this issue with the current definitions and updates, but
important point is that I used .bat, .html and .eml file types with the
magic byte of .exe file - I believe that such vulnerability can be
implemented with other file types and possibly with other magic byte. The
vendors must patch the LOGIC (algorithm) of the scanning to address this
issue.

Best regards,
Andrey Bayora.



----- Original Message -----
From: <mgotts@2roads.com>
To: "Andrey Bayora" <andrey@securityelf.org>
Cc: <bugtraq@securityfocus.com>
Sent: Friday, October 28, 2005 6:52 PM
Subject: Re: Multiple Vendor Anti-Virus Software Detection Evasion
Vulnerability through


> > > Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability
> through
> > > forged magic byte.
> >
> > > AUTHOR: Andrey Bayora (www.securityelf.org)
> >
> > > For more details, screenshots and examples please read my article "The
> Magic
> > > of magic byte" at www.securityelf.org . In addition, you will find a
> sample
> > > "triple headed" program which has 3 different 'execution entry
> points',
> > > depending on the extension of the file (exe, html or eml) - just
> change the
> > > extension and the SAME file will be executed by (at least) THREE
> DIFFERENT
> > > programs! (thanks to contributing author Wayne Langlois from
> > > www.diamondcs.com.au).
> >
>
> Below I copied Trend Micro's response to the "magic byte" vulnerability in
> their products:
>
> ========================================
> Dear Valued Client,
>
> Greetings!
>
> My name is <removed>. I will be the one handling your case.
>
> Please correct me if I left some issues or if I misunderstood your
> concern.
>
> Trend Micro is aware of a potential vulnerability related to the "forged
> magic byte" in certain file types. Based on our analysis, this
> vulnerability is limited in our products to one specific type of potential
> virus file which is not commonly allowed in most IT systems and needs to
> be executed manually. Trend Micro customers are currently able to detect
> such files -- should they be created -- through our virus pattern file,
> 2.915.00.
>
> Please make sure that you regularly update your virus definitions. Hope
> this information helps.
>
> ========================================
>
>
> Any comments on their response?
>
> -- Mark
>
>