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.
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.