Multiple AV Vendors Incorrect CRC32 Bypass Vulnerability

Hi,

An other vulnerability which concerns many vendors:

http://www.geocities.com/visitbipin/crc.html

The zip test file is just a variant of Eicar.
Tested on VirusTotal: except Fortinet and Ikarus, all AVs have failed.

Integrity checking is one of the weakness of AVs.

Regards

 

F-Prot and Panda detected too.

Best regards,
Firefighter!

 

Maybe I dont understand something but to me it looks like a major bs.
First of all, if you can extract it with Winrar, Winzip, Info zip - then there is no problem - your computer will not get infected. And when you finally will extract it - antivirus program will pick it up.
I tried to fix this crc error using winrar - no luck. InfoZip was able to extract part of it, and it added file name inside of that file - if it was executable most likely it will not even run.

Update: PkZip did same thing as InfoZip, and Advanced Zip Repair did not help either.
Unless someone tells me how to repair that zip file there is no point of talking about "Vulnerability".


Mariusz

 

I'm not sure I understand this vulnerability - I thought that if the CRC is incorrect and therefore is seen as corrupt, the file can't be extracted in toto from the zip archive. How would this pose and infection vector if it was a virus/trojan?

edit:
Opps - too late, duplicate concern.

 

Hey...he's right...This really ain't anything to worry about then.

 

pointless thread lol
but interesting none the less

 

Well, it would be more interesting if that guy had patched the ZIP file correctly. He did patch more than just the CRC32 field of the ZIP header - no program is able to unpack EICAR from this archive anymore. The archive is completely damaged. The AV scanners which still detected EICAR in here just do signature scanning over ZIP files without unpacking them

However, if you properly patch the CRC32 field only, there are tools that still unpack EICAR - but also basically every AV scanner will detect it then.

 

Hi,


***Firefighter

My memory has forgotten Panda and F-Prot.
Thks for your vigilance.

***More funny:

I've converted the zip file on a "tar.gz" archive.
Conclusion: NO AV was able to detect the eicar test (see the image).

It's not new that AVs have some difficulties to scan archives.
As the the JPEG test, this one just try to demonstrate that AV vendors have to increase their scan engines.

Regards

 

I have explained this many times and i still belive i'm the most correct.
Every (i mean really every) archive acts the same as antivirus quarantine.
For as long as file is inside it cannot do any harm.
It doesn't matter if the archive is modified,hacked or anything. Last entry point is always extraction of archive. In that case file gets "decrypted" and standard On-Access (Real-Time) module can pick the file as any other.
Archives corrupted beyond usability cannot do any harm since viral payload cannot be even extracted. Whole fuss is just about scanners missing such samples when archive scanning is enabled for On-Access (very rare and major performance hit factor). But again we don't care about that,the archive can go pass the scanner,but payload inside cannot.

 

Just quick question - did you read any of the messages posted here?
Mariusz

 

And in any case even a *.GZ (or any other archive at all) archive will have the same problems as the ZIP archive upon extraction. Am I right?

 

err...
I don't think AV vendors unpack GZip format yet.

Also... I have to agree with stormbyte...
Incorrect CRC = damaged archive. Simple.

 

Why, most actually do handle it. It's no big problem. .tar.bz2 might
be a problem for some.

It's not that simple, some unpacking tools ignore the CRC field and
will unpack damaged/patched ZIP files. The test archive presented
here is completely damaged, though - there were more parts of the
ZIP header overwritten than just the CRC32 field.

So, it's a valid test but it was performed wrong.

 

Hi,

***As said Stefan K."it's a valid test but it was performed wrong".

Ive tried to repair the file with ZipRepairPro ( http://www.zip-repair.com/ ) but it wasn't possible.

BY analyzing the file inside (see the image), it seems a little bit falsified in comparison with the original eicar: http://www.eicar.org/download/eicar.com.txt

The test was done by removing the file name size.
And therefore, the eicar.com become invalid.


***Regarding the tar.gz ability of AVs, i think it's not my problem...until i buy one of them.

Then, it will be a problem.

Yes, i've read the posts above.So what?

AV vendors defend their products, AV users defend their rights.
That's all.

Thanks for the feedbacks.

Regards

 

Now...check my profile info, I am no simple AV 'user'. I am a tester.

 

Re: Not just 1 flaw!

Download Accelerator Plus repares the archive!

------------------------------------------------------------------
Multiple AV Vendors MULTIPLE Vulnerabilities.

Affected Product:


BitDefender 7.0
DrWeb 4.32b
eTrust-Iris 7.1.
eTrust-Vet 11.7.
Fortinet 2.51
McAfee 4445
Norman 5.70.10
Sybari 7.5.1314
Symantec 8.0
F-Prot 3.16a
Kaspersky
McAfee 4445
( Updated March 11, 2004 14:00 GMT )

(UPDATED: 16:00 GMT, Friday, March 10, 2005 ).
Description:
1). If you create a zip archive with invalid CRC checksum...... some AV skip the archive marking it as clean........ by this way, you can bypass antivirus gateways and slip in any attachment without scanning the archive. Moreover, these days.... software tools automatically repair a *broken* archive.

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

2). 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, because the AV come to a false assumption that zip file is encrypted. This was discovered 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


3). If you have a long archive comment... in a zip archive these AV can't detect virus embedded in it. I came to know Symantec 8.1 is immune to the bug? Though, running the scan through www.virustotal.com reveals F-prot, DrWeb, *Symantec 8.0 are vulnerable. (Discovered, long ago)

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



In the 'local file header" & "data descriptor" if you change the compressed size and uncompressed size to ZERO [iDEFENSE] or greater than the actual file size or less than the actual file size still there are many AV that can't scan the file properly. http://www.geocities.com/visitbipin/Antigen_b.zip

P0C: http://www.geocities.com/visitbipin/Antigen.zip <--- try

http://www.geocities.com/visitbipin/Antigen_s.zip

Moreover there are unzip utilities that goes to a loop if the file size is changed to ffffffff ! Lets hope, AV don't have such faulty code! Just run the file through www.virustotal.com and you'll see. (I know, they aren't using up-to-date scan engine)



regards,
bipin gautam

Useful Reference: http://www.pkware.com/company/standards/appnote/

Vendor notification: I've lost faith in responsible disclosure... long ago! Moreover, vendors don't respond in timely manner.

regards,
Bipin Gautam
http://www.geocities.com/visitbipin/


Disclaimer: The information in the advisory is believed to be accurate at the time of printing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect or consequential loss or damage arising from use of, or reliance on this information.