[Clamav-devel] Is this how clamAV is intended to work?

Andy Singer andy at orbitech.org
Thu Mar 5 13:42:50 EST 2015


Hi,
It depends on how the signature was written. In the case of eicar, it is
Eicar-Test-Signature:0:0:58354f2150254041505b345c505a58353428505e2937434329377d2445494341522d5354414e444152442d414e544956495255532d544553542d46494c452124482b482a

so it will only be detected only if the eicar pattern is at position 0 of
the file. If you change the signature to

Eicar-Test-Signature:0:*:58354f2150254041505b345c505a58353428505e2937434329377d2445494341522d5354414e444152442d414e544956495255532d544553542d46494c452124482b482a

the file will be detected regardless of where the pattern appears. In the
case of WIN.Trojan.DarkKomet, the signature is,

WIN.Trojan.DarkKomet:1:*:657473746174202d61202d6e202d6f00000000ffffffff0d00000044444f5348545450464c4f4f44000000ffffffff0c00000044444f5353594e464c4f4f4400000000ffffffff0c00000044444f53554450464c4f4f4400000000ffffffff0a0000005b436861

This can be present anywhere in a file, but only if it's a PE file. If you
prepend random data to the file, it will no longer have an MZ header, and
ClamAV will not recognize it as a PE file, so the signature will be
ignored. In the signature, change the target (1= PE) to (0= any) and you
can prepend random data.

ClamAV was designed for scanning files, not shellcode. If a file doesn't
have an MZ header, Windows won't execute it, so there's no need for ClamAV
to continue checking for PE signatures.

On Thu, March 5, 2015 1:11 pm, Tyler Manson wrote:
>

> Hello,
>
>
> Apologies if this email is to the wrong list. I discovered what I
> believe may be a problem with clamscan, and I don't know if this is how
> clamscan is intended to work or not, but I thought I should share my
> findings regardless.
>
> So I was playing around with the EICAR-STANDARD-ANTIVIRUS-TEST-FILE you
> can download from the internet. I was testing if I could hide it from
> clamAV.
>
> If you run clamscan on it, it catches it:
>
>
>
> malicious: Eicar-Test-Signature FOUND
>
>
> ----------- SCAN SUMMARY -----------
> Known viruses: 3757394
> Engine version: 0.98.6
> Scanned directories: 0
> Scanned files: 1
> Infected files: 1
> Data scanned: 0.00 MB
> Data read: 0.00 MB (ratio 0.00:1)
> Time: 7.707 sec (0 m 7 s)
>
>
>
>
>
> But if you were to do something like:
>
>
> $ dd if=/dev/urandom bs=1000 count=3 of=/home/user/randomData
>
>
> and then
>
> $ cat randomData eicar.txt > malicious2
> $ clamscan malicious2
>
>
> malicious2: OK
>
>
> ----------- SCAN SUMMARY -----------
> Known viruses: 3757394
> Engine version: 0.98.6
> Scanned directories: 0
> Scanned files: 1
> Infected files: 0
> Data scanned: 0.00 MB
> Data read: 0.00 MB (ratio 0.00:1)
> Time: 7.724 sec (0 m 7 s)
>
>
>
>
> But if you do it the other way around:
>
>
> $ cat eicar.txt randomData > malicious3
> $ clamscan
>
>
> malicious3: Eicar-Test-Signature FOUND
>
>
> ----------- SCAN SUMMARY -----------
> Known viruses: 3757394
> Engine version: 0.98.6
> Scanned directories: 0
> Scanned files: 1
> Infected files: 1
> Data scanned: 0.00 MB
> Data read: 0.00 MB (ratio 0.00:1)
> Time: 7.784 sec (0 m 7 s)
>
>
> So my first inclination was okay, this is just random data garbage at
> the beginning of the file. So maybe that's why clamscan doesn't bother
> catching it, as it's unusable for anything anyway (unless you can force
> your victim jump 3MB into the file!), and you know, it's not executable if
> it doesn't have a valid file header, so I guess it's okay. That might
> explain why it'll catch the exploit with random data appended, but not
> prepended. So just to make sure, let's test if it'll catch it with a valid
> file header:
>
> $ vim tiny.asm
>
>
> ; tiny.asm
> BITS 32
> SECTION .data
> db "X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*"
> EXTERN _exit
> GLOBAL _start
> SECTION .text
> _start:
> push    dword 42 call    _exit
>
> So all this does is load 42 on the stack, and call exit, with a payload
> stored in the data segment. But it's not hard to imagine how one might be
> able to make such a thing malicious, right - depending on if DEP/NX is
> enabled, you can jump into your payload, etc etc. But in any case, I would
> think most people would expect clamscan to want to catch this binary based
> on it having a malicious payload, which it doesn't:
>
> $ nasm -f elf tiny.asm
> $ gcc -m32 -Wall -s -nostartfiles tiny.o -o tiny
> $ clamscan tiny
>
>
> tiny: OK
>
>
> ----------- SCAN SUMMARY -----------
> Known viruses: 3757394
> Engine version: 0.98.6
> Scanned directories: 0
> Scanned files: 1
> Infected files: 0
> Data scanned: 0.00 MB
> Data read: 0.00 MB (ratio 0.00:1)
> Time: 7.756 sec (0 m 7 s)
>
>
>
> Okay. So maybe this is just that Eicar is a fake virus and the signature
> for it is meh. I'm still a little confused why it doesn't catch the virus
> in the middle or at the end of a file, but maybe it's all because Eicar is
> meant to be for testing. Let's use some live munitions:
>
> $ clamscan 03266ad1af1606c60b250c6e163ccb60
>
>
> 03266ad1af1606c60b250c6e163ccb60: WIN.Trojan.DarkKomet FOUND
>
>
> ----------- SCAN SUMMARY -----------
> Known viruses: 3757394
> Engine version: 0.98.6
> Scanned directories: 0
> Scanned files: 1
> Infected files: 1
> Data scanned: 0.62 MB
> Data read: 11.93 MB (ratio 0.05:1)
> Time: 7.847 sec (0 m 7 s)
>
>
> Okay, cool beans. What about when we prepend some random data?
>
>
> $ cat randomData 03266ad1af1606c60b250c6e163ccb60 > testthing
>
>
> testthing: OK
>
>
> ----------- SCAN SUMMARY -----------
> Known viruses: 3757394
> Engine version: 0.98.6
> Scanned directories: 0
> Scanned files: 1
> Infected files: 0
> Data scanned: 12.04 MB
> Data read: 11.93 MB (ratio 1.01:1)
> Time: 8.291 sec (0 m 8 s)
>
>
> $ cat 03266ad1af1606c60b250c6e163ccb60 randomData > testthing2
>
>
> testthing2: WIN.Trojan.DarkKomet FOUND
>
>
> ----------- SCAN SUMMARY -----------
> Known viruses: 3757394
> Engine version: 0.98.6
> Scanned directories: 0
> Scanned files: 1
> Infected files: 1
> Data scanned: 0.62 MB
> Data read: 11.93 MB (ratio 0.05:1)
> Time: 7.827 sec (0 m 7 s)
>
>
>
> This is where I stopped my research, and figured I should send this
> email as a heads up and to ask what's going on. Is this the intended way
> ClamAV is supposed to work? Is it truly a problem in the first place?
> Some people can argue that the random bytes at the beginning of the file
> essentially make it useless as an exploit - but I could see a way to
> weaponize this with a binary that would load the Program
> Counter/Instruction Pointer to the offset into the file and then continue
>  executing the malicious code. Also hiding the payload in the data segment
> of another binary could potentially present another vector of attack. What
> do you guys think? I don't know the internals of clamscan to know why it's
> missing certain things, but catching others.
>
>
> -- Tyler
>
>
> --
> The preceding email was cryptographically signed to provide verification
> that I personally authored it, and that it was not modified in transit.
>
> Privacy in communications is a fundamental human right codified in
> Article 12 of The Universal Declaration of Human Rights. Organizations
> and individuals that participate in the mass surveillance of internet
> communications are committing crimes against humanity.
>
> In order to resist those that seek to abuse the powers of technology, as
> well as to explicitly establish an objective expectation of privacy, I
> strongly recommend the use of PGP encryption in all private dialogue
> between individuals, yourself and myself included. My public key
> fingerprint is published in the X-PGP-KEY header of this email, and is
> searchable at pgp.mit.edu.
>
> To learn about encrypting your own emails, go to
> https://emailselfdefense.fsf.org/
>
>
> This email signature, separate from the actual contents of the above
> email, is hereby published into the public domain. You may copy and attach
> it to your own correspondence at your will.
> _______________________________________________
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
>
>
> http://www.clamav.net/contact.html#ml




More information about the clamav-devel mailing list