RE: Re: Multiple AV Vendor Incorrect CRC32BypassVulnerability.

["Steve Scholz" <steve_scholz () sybari com>]

" Nor, anything else in the archive was modified!"
You changed the bit that determines if the zip is encrypted!
In Local file header if you modify "general purpose
bit flag" 7th & 8'th byte of a zip archive with \x2f 

You changed bit 0 by making the above changes.

general purpose bit flag: (2 bytes)

          Bit 0: If set, indicates that the file is encrypted.

          (For Method 6 - Imploding)
          Bit 1: If the compression method used was type 6,
                 Imploding, then this bit, if set, indicates
                 an 8K sliding dictionary was used.  If clear,
                 then a 4K sliding dictionary was used.
          Bit 2: If the compression method used was type 6,
                 Imploding, then this bit, if set, indicates
                 3 Shannon-Fano trees were used to encode the
                 sliding dictionary output.  If clear, then 2
                 Shannon-Fano trees were used.

          (For Methods 8 and 9 - Deflating)
          Bit 2  Bit 1
            0      0    Normal (-en) compression option was used.
            0      1    Maximum (-exx/-ex) compression option was used.
            1      0    Fast (-ef) compression option was used.
            1      1    Super Fast (-es) compression option was used.

          Note:  Bits 1 and 2 are undefined if the compression
                 method is any other.

          Bit 3: If this bit is set, the fields crc-32, compressed 
                 size and uncompressed size are set to zero in the 
                 local header.  The correct values are put in the 
                 data descriptor immediately following the compressed
                 data.  (Note: PKZIP version 2.04g for DOS only 
                 recognizes this bit for method 8 compression, newer 
                 versions of PKZIP recognize this bit for any 
                 compression method.)

          Bit 4: Reserved for use with method 8, for enhanced
                 deflating. 

          Bit 5: If this bit is set, this indicates that the file is 
                 compressed patched data.  (Note: Requires PKZIP 
                 version 2.70 or greater)

          Bit 6: Strong encryption.  If this bit is set, you should
                 set the version needed to extract value to at least
                 50 and you must also set bit 0.  If AES encryption
                 is used, the version needed to extract value must 
                 be at least 51.

          Bit 7: Currently unused.

          Bit 8: Currently unused.

          Bit 9: Currently unused.

          Bit 10: Currently unused.

          Bit 11: Currently unused.

          Bit 12: Reserved by PKWARE for enhanced compression.

          Bit 13: Used when encrypting the Central Directory to indicate

                  selected data values in the Local Header are masked to
                  hide their actual values.  See the section describing 
                  the Strong Encryption Specification for details.

          Bit 14: Reserved by PKWARE.

          Bit 15: Reserved by PKWARE.


By doing this you did flip the bit that determines if a pkzip type file
is considered encrypted. While the file itself might not be you made the
program think that it is.

I believe this counts as changing something in the archive please
correct me if I am wrong. And since all encrypted files can contain
viruses with a password in the email it would be a very good idea to
delete encrypted zip files from emails.

As I have already stated Antigen by default has the ability to do such a
thing. Also even if the archive is not encrypted and the header info has
been changed to trick the decompression utility to believe it is then it
should be deleted.

While it might be a vulnerability if the file is extracted which it has
to be to be executed the desktop scanner will detect it at that time. 

Multiple layers of defense is your best option

As far as number 3 Antigen detects Eicar.
Antigen for SMTP found long_coment.zip->eicar.com.txt infected with the
EICAR test string virus. 
The file is currently Removed.  The message, "test", was 
sent from Steve Test and was discovered in SMTP Messages\Internal 
located at Sybari Software/SYB-NY-ASD.

Number 1.
Well you had both the crc change and the change to the general purpose
bit flag combined. Once I changed this back to 00 00 as a normal non
encrypted archive would be while leaving your crc change in place
Antigen detected it with no problem.

Antigen for SMTP found crc.zip->eicar.com infected with
EICAR_Test_file_not_a_virus virus.
The file is currently Removed.  The message, "test", was sent from Steve
Test and was discovered in SMTP Messages\Internal located at Sybari
Software/SYB-NY-ASD. I have included my version of your crc.zip the
password is crc please let me know if this is what you intended for the
file to do. Also feel free to contact me or give me a phone number I can
contact you by so I can see if there is anything else that you do not
think Antigen is doing correctly.
 

Steve Scholz
Corporate Sales Engineer-North America
Sybari Software, Inc.
631-630-8556 Direct
516-903-2464 Mobile

Email:  Steve_scholz () sybari com

MSN IM:Steve_Scholz () Msn com (email never checked) 




-----Original Message-----
From: full-disclosure-bounces () lists grok org uk
[mailto:full-disclosure-bounces () lists grok org uk] On Behalf Of bipin
gautam
Sent: Friday, March 11, 2005 9:33 PM
To: full-disclosure () lists grok org uk; vuldb () securityfocus com
Cc: vuln () secunia com
Subject: RE: [Full-disclosure] Re: Multiple AV Vendor Incorrect
CRC32BypassVulnerability.

1'st issue: Could anyone verify the existance of both
vulnebrility in *Symantec products* cauz it seems like
symantec engineers got the *old* broken file that i
reported lately and couldn't reproduce the thing. I
tried reporting the issue but the message had a broken
eicarta string so i think the message wasn't deliverd!
I uploaded a wrong file before and the same old file
kept on comming from the servers cache. I was able to
transperently extract the broken CRC archive using
Download accelerator Plus(5.3) with just a warning
message.

2'nd issue: NOP, the zip file wasn't "ACTUALLY"
encrypted.  Nor, anything else in the archive was
modified! The archive can be normally be extracted by
any unzip utility. I did tested it with winrar 3.2 &
with default zip manager of winxp (sp2).

3'rd issue(NEW): Well, tested with F-prot, DrWeb,
*Symantec 8.0 long ago... lately verified it using
virustotal.com If you have a long archive coment... in
a zip archive these AV can't detect virus embedded in
it. though a frend of mine reported me symantec 8.1 is
immune to the bug.

POC:
http://www.geocities.com/visitbipin/long_coment.zip


--- Randall M <randallm () fidmail com> wrote:
> I scanned the file with McAfee 8.0i and it end up
> stating that it couldn't
> scan the EICAR.COM file because it was encrypted.
> Was this your
> Intention?
>
> ------------------------------
--- Steve Scholz <steve_scholz () sybari com> wrote:

> You are correct by doing this you are marking the
> zip file as encrypted.
>
> Your option at this time is to turn on the feature
> delete encrypted
> compressed files.

> Steve Scholz
> Corporate Sales Engineer-North America
> Sybari Software, Inc.
> 631-630-8556 Direct
> 516-903-2464 Mobile
>
> Email:  Steve_scholz () sybari com
>
> -----Original Message-----
> From: full-disclosure-bounces () lists grok org uk
> Subject: [Full-disclosure] Re: Multiple AV Vendor
> Incorrect CRC32
> BypassVulnerability.
>
> In Local file header if you modify "general purpose
> bit flag" 7th & 8'th byte of a zip archive with \x2f
> ie: "\" F-port, Kaspersky, Mcafee, Norman, Sybari,
> Symantec seem to skip the file marking it as
> clean!!!
> This was discoverd during the analysis of "Multiple
> AV
> Vendor Incorrect CRC32 Bypass Vulnerability."
>
> Quick/rough conclusion were drawn using
> www.virustotal.com
>
> poc: http://www.geocities.com/visitbipin/gpbf.zip
>
> regards,
> bipin gautam



                
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://www.secunia.com/

Attachment: crc changed.zip
Description: crc changed.zip

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://www.secunia.com/