Multiple AV Vendors Incorrect CRC32 Bypass Vulnerability

Discussion in 'other anti-virus software' started by kareldjag, Mar 10, 2005.

Thread Status:
Not open for further replies.
  1. kareldjag

    kareldjag Registered Member

    Joined:
    Nov 13, 2004
    Posts:
    622
    Location:
    PARIS AND ITS SUBURBS
    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
     
  2. Firefighter

    Firefighter Registered Member

    Joined:
    Oct 28, 2002
    Posts:
    1,670
    Location:
    Finland
    F-Prot and Panda detected too.

    Best regards,
    Firefighter!
     

    Attached Files:

  3. stormbyte

    stormbyte AV Expert

    Joined:
    Jul 9, 2004
    Posts:
    97

    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
     
    Last edited: Mar 10, 2005
  4. Mem

    Mem Registered Member

    Joined:
    Mar 7, 2005
    Posts:
    292
    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.
     
    Last edited: Mar 10, 2005
  5. Firecat

    Firecat Registered Member

    Joined:
    Jan 2, 2005
    Posts:
    7,927
    Location:
    The land of no identity :D
    Hey...he's right...This really ain't anything to worry about then.
     
  6. LouKaNiKo

    LouKaNiKo Registered Member

    Joined:
    Mar 8, 2005
    Posts:
    13
    pointless thread lol
    but interesting none the less :cool:
     
  7. Stefan Kurtzhals

    Stefan Kurtzhals AV Expert

    Joined:
    Sep 30, 2003
    Posts:
    701
    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.
     
  8. kareldjag

    kareldjag Registered Member

    Joined:
    Nov 13, 2004
    Posts:
    622
    Location:
    PARIS AND ITS SUBURBS
    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
     

    Attached Files:

  9. RejZoR

    RejZoR Registered Member

    Joined:
    May 31, 2004
    Posts:
    6,426
    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.
     
    Last edited: Mar 11, 2005
  10. stormbyte

    stormbyte AV Expert

    Joined:
    Jul 9, 2004
    Posts:
    97

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

    Firecat Registered Member

    Joined:
    Jan 2, 2005
    Posts:
    7,927
    Location:
    The land of no identity :D
    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?
     
  12. no13

    no13 Retired Major Resident Nutcase

    Joined:
    Sep 28, 2004
    Posts:
    1,327
    Location:
    Wouldn't YOU like to know?
    err...
    I don't think AV vendors unpack GZip format yet.

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

    Stefan Kurtzhals AV Expert

    Joined:
    Sep 30, 2003
    Posts:
    701
    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.
     
  14. kareldjag

    kareldjag Registered Member

    Joined:
    Nov 13, 2004
    Posts:
    622
    Location:
    PARIS AND ITS SUBURBS
    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
     

    Attached Files:

  15. Firecat

    Firecat Registered Member

    Joined:
    Jan 2, 2005
    Posts:
    7,927
    Location:
    The land of no identity :D
    Now...check my profile info, I am no simple AV 'user'. I am a tester. :)
     
  16. whyqwerty

    whyqwerty Guest

    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.
     
Loading...
Thread Status:
Not open for further replies.