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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20051027045100.k4cwwx8e4ogsgoww@www.securityelf.org>
Date: Thu Oct 27 10:55:02 2005
From: andrey at securityelf.org (Andrey Bayora)
Subject: Re: Multiple Vendor Anti-Virus Software Detection
	Evasion Vulnerability through forged magic byte

Dear Ken,

> If your altered virus sample
> still executes correctly, you have simply created a new virus
> variant.

Not exactly, please look at this virustotal.com log
http://www.securityelf.org/updmagic.html

The altered (120 bytes prepended) TXT_* variant is STILL detected by your
product (CA), but when I change the first byte from "Z" to "M" - your product
fails (MZ_* variant).
I believe, that if I PREPEND 120 bytes to known virus and the virus is still
detected with the SAME signature - then I DID NOT create a new variant.
Now one more example: try to change the first byte "Z" in the TXT_* variant to
any value, but not to "M" - this virus will be detected, but when you 
change to
"M", thus creating the .EXE magic byte - the variant is not detected !!!
My conclusion: the antivirus ?thought? that the file is the executable type
instead of determining the file type by the extension.

That is my point, if you still think that your product is OK - do not do
anything.

Regards,
Andrey Bayora.


Quoting "Williams, James K" <James.Williams@...com>:

>
>> Subject: Re: Multiple Vendor Anti-Virus Software Detection
>> Evasion Vulnerability through forged magic byte
>> From: "Andrey Bayora" <andrey () securityelf ! org>
>> Date: 2005-10-25 3:07:51
>>
>> [...]
>>
>> VULNERABLE vendors and software (tested):
>>
>> [...]
>>
>> 3.  eTrust CA (ver 7.0.1.4, engine 11.9.1, vir sig. 9229)
>>
>> [...]
>> 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.
>
> Andrey,
>
> Thank you for the report.
>
> You are effectively altering existing viruses to the point that
> AV scanners do not detect them.  If your altered virus sample
> still executes correctly, you have simply created a new virus
> variant.  If your altered virus sample does not execute properly,
> you have created nothing more than a corrupt virus sample.
>
> 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".
>
> Note that CA eTrust Antivirus, when running in Reviewer mode,
> should already detect these new variants.
>
> Regards,
> Ken
>
> Ken Williams ; Dir. Vuln Research
> Computer Associates ; 0xE2941985
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ