In this article over at CNET, one of the things they discuss is using An Ubuntu Live CD, included with ClamAV to help repair infected computers.
Article here
Monday, May 28, 2012
Monday, April 9, 2012
The VRT is looking for an Intern to assist with the ClamAV and Razorback projects. If you are a C coder, we'd like to hear from you.
We are looking for resumes sent to research [at] sourcefire.com. Please let us know that you are interested in the Intern position with the VRT, and that you saw the blog post here on the ClamAV blog!
We are looking for resumes sent to research [at] sourcefire.com. Please let us know that you are interested in the Intern position with the VRT, and that you saw the blog post here on the ClamAV blog!
Wednesday, March 21, 2012
The ClamAuth kernel extension enables ClamAV to provide on-access scanning for Mac OS X 10.5 and later.
The current version works in a passive mode only - ClamAV will log the detection but won't block access to the infected file. However, it's possible to perform special actions (eg. quarantine files) with the VirusEvent directive of clamd.
Usage
-----
1. Run ClamAuth_load to load the kernel extension (you can edit the script to change or add more paths that will be monitored).
2. Add "ClamAuth yes" to your clamd.conf (ClamAV 0.97.4) or "ScanOnAccess yes" (ClamAV-devel)
3. Start clamd with root privileges ('sudo /usr/local/sbin/clamd')
If clamd properly connects to the driver, you should see a line like this in the log file:
ClamAV is now monitoring the paths specified in ClamAuth_load.
If you have any questions or feedback about this module please send it to the ClamAV mailing list here:
http://www.clamav.net/lang/en/ml/
The current version works in a passive mode only - ClamAV will log the detection but won't block access to the infected file. However, it's possible to perform special actions (eg. quarantine files) with the VirusEvent directive of clamd.
Usage
-----
1. Run ClamAuth_load to load the kernel extension (you can edit the script to change or add more paths that will be monitored).
2. Add "ClamAuth yes" to your clamd.conf (ClamAV 0.97.4) or "ScanOnAccess yes" (ClamAV-devel)
3. Start clamd with root privileges ('sudo /usr/local/sbin/clamd')
If clamd properly connects to the driver, you should see a line like this in the log file:
ClamAuth: Driver version: 0.3, protocol version: 2
ClamAV is now monitoring the paths specified in ClamAuth_load.
If you have any questions or feedback about this module please send it to the ClamAV mailing list here:
http://www.clamav.net/lang/en/ml/
Monday, March 19, 2012
ClamAV 0.97.4 includes minor bugfixes, detection improvements and
initial support for on-access scanning under Mac OS X (see
contrib/ClamAuth).
This update is recommended for all users.
Download : http://downloads.sourceforge.net/clamav/clamav-0.97.4.tar.gz
PGP sig : http://downloads.sourceforge.net/clamav/clamav-0.97.4.tar.gz.sig
Bugfixes : http://www.clamav.net/release-info/bugs/0.97.4
ChangeLog: http://www.clamav.net/release-info/changelog/0.97.4
initial support for on-access scanning under Mac OS X (see
contrib/ClamAuth).
This update is recommended for all users.
Wed Feb 29 18:35:45 CET 2012 (acab)
-----------------------------------
* libclamav/bytecode.c: reset to BYTECODE_AUTO mode at db reload so that
we don't fail to re-enable or re-disable it again
(bb#3789)
Tue Jan 17 11:15:57 CET 2012 (acab)
-----------------------------------
* misc: performance improvement for HP-UX PA-RISC - patch from
Michael Pelletier <michael.v.pelletier*raytheon.com> (bb#3926)
Fri Nov 4 00:52:21 CET 2011 (acab)
-----------------------------------
* libclamav/pe.c: parse vinfo where varfileinfo occours before stringfileinfo
(bb#3062)
Fri Mar 2 19:48:36 CET 2012 (tk)
---------------------------------
* clamd: add support for on-access scanning on OS X with ClamAuth (beta)
Wed Feb 29 17:02:18 EET 2012 (edwin)
------------------------------------
* libclamav/bytecode_api*: Fix Sparc crash (bb #4324)
Tue Feb 7 23:23:48 CET 2012 (tk)
---------------------------------
* libclamav: fix bytecode whitelisting
Wed Jan 25 18:56:44 CET 2012 (tk)
---------------------------------
* libclamav: fix macro detection in OLE2BlockMacros (bb#4269)
Thu Dec 1 15:07:49 CET 2011 (tk)
---------------------------------
* libclamav/readdb.c: allow comments in all db files (bb#3930)
Fri Nov 18 15:23:50 CET 2011 (tk)
---------------------------------
* libclamav/scanners.c: use lsigs when scanning vba data (bb#3922)
Fri Nov 18 15:48:59 EET 2011 (edwin)
-----------------------------------
* libclamav/matcher-hash.c: Fix SIGBUS on PA-RISC (big-endian) architectures (bb #3894).
Download : http://downloads.sourceforge.net/clamav/clamav-0.97.4.tar.gz
PGP sig : http://downloads.sourceforge.net/clamav/clamav-0.97.4.tar.gz.sig
Bugfixes : http://www.clamav.net/release-info/bugs/0.97.4
ChangeLog: http://www.clamav.net/release-info/changelog/0.97.4
Tuesday, February 28, 2012
Then we want to talk to you! While you can look up the different openings that the Vulnerability Research Team (VRT) has, what you won't see if why you should choose Sourcefire for your next job. This is why I love working here, in no particular order:
1. The people. We come from different backgrounds and bring a wealth of talent and knowledge to the table. Most of us were using computers pre-Internet before we were 10 years old. Back then, our friends were just happy to have a gaming console and didn't see the point of having a computer. We are curious by nature and didn't stop learning when we got our various degrees. When you engage in conversation with the VRT, be assured that there will be someone who knows at least as much as you on any topic. The VRT is made of smart, smart! individuals and we are looking for people who are driven and can fit in the team culture.
2. Open-source philosophy. Whether it's ClamAV, Snort, or Razorback (and their respective signatures/rules), we believe in letting users see and understand what we do, how we do it, and why we do it. This pushes us to excel at our job and always put the customer first.
3. Fun work environment. We are productive and have crunch times, yet we always know how to have fun. Do you know what "tea time" is? "Truffle shuffle"? "Hit box!"? Do you know what it is "to be slothed"? What does it mean when someone calls "car"? Who's the "grammar police"? Come find out :-)
4. Hobbies. If you like biking, riding motorcycles, playing the guitar, photography, playing tennis or soccer, you will likely find an after-hours hangout buddy with similar interest in the VRT.
5. Lunch. Delivered to you every day between 12PM and 2PM. Just choose what you like from 3 different and rotating restaurant menus and lookout for the the daily email that says that your lunch has arrived. For free. Yup, just like that (well technically it's part of your benefits).
6. Training. Whether you want to informally learn about malware or vulnerability research, attend a conference or a week-long training, or formally work towards a Bachelor's or Master's degree, we'll hook you up.
7. Leadership and Innovation. Snort is the de facto standard for Intrusion Detection and Prevention. ClamAV sets the standard for open-source antivirus and anti-malware solutions. Razorback advances complex threat detection and protection.
I could really go on and on about why you should choose us. If you think you have the right skills, if you think you can grow and most importantly if you are driven, contact us with your resume at research at sourcefire dot com.
1. The people. We come from different backgrounds and bring a wealth of talent and knowledge to the table. Most of us were using computers pre-Internet before we were 10 years old. Back then, our friends were just happy to have a gaming console and didn't see the point of having a computer. We are curious by nature and didn't stop learning when we got our various degrees. When you engage in conversation with the VRT, be assured that there will be someone who knows at least as much as you on any topic. The VRT is made of smart, smart! individuals and we are looking for people who are driven and can fit in the team culture.
2. Open-source philosophy. Whether it's ClamAV, Snort, or Razorback (and their respective signatures/rules), we believe in letting users see and understand what we do, how we do it, and why we do it. This pushes us to excel at our job and always put the customer first.
3. Fun work environment. We are productive and have crunch times, yet we always know how to have fun. Do you know what "tea time" is? "Truffle shuffle"? "Hit box!"? Do you know what it is "to be slothed"? What does it mean when someone calls "car"? Who's the "grammar police"? Come find out :-)
4. Hobbies. If you like biking, riding motorcycles, playing the guitar, photography, playing tennis or soccer, you will likely find an after-hours hangout buddy with similar interest in the VRT.
5. Lunch. Delivered to you every day between 12PM and 2PM. Just choose what you like from 3 different and rotating restaurant menus and lookout for the the daily email that says that your lunch has arrived. For free. Yup, just like that (well technically it's part of your benefits).
6. Training. Whether you want to informally learn about malware or vulnerability research, attend a conference or a week-long training, or formally work towards a Bachelor's or Master's degree, we'll hook you up.
7. Leadership and Innovation. Snort is the de facto standard for Intrusion Detection and Prevention. ClamAV sets the standard for open-source antivirus and anti-malware solutions. Razorback advances complex threat detection and protection.
I could really go on and on about why you should choose us. If you think you have the right skills, if you think you can grow and most importantly if you are driven, contact us with your resume at research at sourcefire dot com.
Wednesday, January 25, 2012
Open Source Fact and Fiction: Sourcefire Stays True To Its Roots
Alan Shimel writes a great article about our new product FireAMP, and it's roots, not only with ClamAV but many other OpenSource technologies. It's a quick read, but really shows what we are trying to do here at Sourcefire and how OpenSource is not only the foundation of our products, but really, is baked into everything that we do here.
Friday, December 9, 2011
Thanks to Christoph Murauer for an excellent guide to installing ClamAV 0.97.3 on Mac OS X!
Check out Christoph's ClamAV 0.97.3 install guide here.
Thanks to all of our ClamAV community contributors on their documentation, if you'd like to contribute some documentation, please feel free to contact me at joel@snort.org.
As always Snort.org makes no warranty or edits to submitted documentation, and we'd like to thank the contributors of the documentation for their time.
Check out Christoph's ClamAV 0.97.3 install guide here.
Thanks to all of our ClamAV community contributors on their documentation, if you'd like to contribute some documentation, please feel free to contact me at joel@snort.org.
As always Snort.org makes no warranty or edits to submitted documentation, and we'd like to thank the contributors of the documentation for their time.
Friday, November 4, 2011
About one year ago Alain presented the LLVM-based ClamAV bytecode. We've realised that, besides that initial introduction, we've never shown any real life use case, nor did we ever demonstrate the incredible power and flexibility of the ClamAV bytecode engine. I'll try to fix that today.
I decided to target the Xpaj virus because it's an polymorphic file infector, which means that it is not easily to detected with plain signatures.
Please note that I'm just focusing on the detection of Xpaj via bytecode signatures, not on Xpaj itself which was already thoroughly reviewed and explained.
Pic.1: Clean file
Pic.2: Same file as above, but infected with Xpaj
For the scope of this blog post, it suffices to say that Xpaj is a file infector targeting 32-bit Windows executables and DLLs which employs entry-point obfuscation (EPO) capabilities in order to make the detection harder. In particular, the virus code hijacks a few API calls in the .text section of the file, diverting them to its own routine.
This routine is located within the .text section and consists of a series of small chunks of code connected by jumps. Most of that is “garbage”. The only thing this preliminary block of code does is compute the code address for the next stage and jump to it. The actual viral code, as well as the overwritten blocks, are stored, in encrypted form, inside the data section.
Well... enough technical info already. From now on I'll just focus on the Xpaj detection, or rather, the detection of a rather simplified version of it in order to keep this blog post small and readable. The geeks can find the full source code here.
Let's start with a look at the virus entry point code:
After that we have some optional trash (do nothing) code, and then the virus saves the content of 3 random registers, which will be clobbered later by both the virus code and the trash engine too.
So far we can still get away with a signature that makes use of a wildcard, however we still don't have much: stack allocation and 3 registers saved. That's still not enough.
Next, we've got the trash engine in all its glory, and eventually we reach a function call.
The trash code may or may not jump to another chunk of code. And that effectively kills our ability to use a normal (ndb or ldb) signature.
Not all is lost, though. We can still write a small piece of bytecode signature which follows the code through the trash and checks for specific fingerprints.
In particular we plan to scan the code section for something that looks like the following:
Back outside the call we have a couple of other less interesting fingerprints and eventually the virus will jump to some runtime computed location. There are two ways by which this is achieved:
Ok let's code...
First we look for the 5 static bytes at the virus entry point (EP):
As for the actual opcode matching, here are a few examples. The first thing we are interested in is the 3 pushes. In terms of bytecode we need to check that:
I decided to target the Xpaj virus because it's an polymorphic file infector, which means that it is not easily to detected with plain signatures.
Please note that I'm just focusing on the detection of Xpaj via bytecode signatures, not on Xpaj itself which was already thoroughly reviewed and explained.
Pic.1: Clean file
Pic.2: Same file as above, but infected with Xpaj
For the scope of this blog post, it suffices to say that Xpaj is a file infector targeting 32-bit Windows executables and DLLs which employs entry-point obfuscation (EPO) capabilities in order to make the detection harder. In particular, the virus code hijacks a few API calls in the .text section of the file, diverting them to its own routine.
This routine is located within the .text section and consists of a series of small chunks of code connected by jumps. Most of that is “garbage”. The only thing this preliminary block of code does is compute the code address for the next stage and jump to it. The actual viral code, as well as the overwritten blocks, are stored, in encrypted form, inside the data section.
Well... enough technical info already. From now on I'll just focus on the Xpaj detection, or rather, the detection of a rather simplified version of it in order to keep this blog post small and readable. The geeks can find the full source code here.
Let's start with a look at the virus entry point code:
push ebpWhile these are technically enough bytes to create a signature based on the opcodes, such a signature would be a really bad idea. What we have there, in fact, is just a pretty standard function entry point.
mov ebp, esp
sub esp, XX
After that we have some optional trash (do nothing) code, and then the virus saves the content of 3 random registers, which will be clobbered later by both the virus code and the trash engine too.
So far we can still get away with a signature that makes use of a wildcard, however we still don't have much: stack allocation and 3 registers saved. That's still not enough.
Next, we've got the trash engine in all its glory, and eventually we reach a function call.
The trash code may or may not jump to another chunk of code. And that effectively kills our ability to use a normal (ndb or ldb) signature.
Not all is lost, though. We can still write a small piece of bytecode signature which follows the code through the trash and checks for specific fingerprints.
In particular we plan to scan the code section for something that looks like the following:
mov edi, ediHere we are inside "$DELTA"..
push ebp
mov ebp, esp
sub esp, $STACKSIZE
[optional trash]
push eax (*)
push edx (*)
push edi (*)
(*) note, the registers are chosen randomly among the 32 bit general purpose registers except esp and ebp
[optional trash]
call $DELTA
[optional trash]
mov register, [ebp-stacksize]
[optional trash]
ret
Back outside the call we have a couple of other less interesting fingerprints and eventually the virus will jump to some runtime computed location. There are two ways by which this is achieved:
jmp local_varor
push local_var
ret
Ok let's code...
First we look for the 5 static bytes at the virus entry point (EP):
seek(begin_of_the_code_section, SEEK_SET);Then we set ourselves in a disassembly loop and we check if we got what we expect. Something along the lines of:
cur = file_find_limit("\x55\x89\xe5\x83\xec", 5, end_of_the_code_section);
if(cur < 0) return 0;
while(1) {
struct DIS_fixed d;
int next = DisassembleAt(&d, cur, space_remaining);
if(next == -1) break; /* disasm error */
cur = next; /* cur now points at the next op */
[here we check the op]
}
As for the actual opcode matching, here are a few examples. The first thing we are interested in is the 3 pushes. In terms of bytecode we need to check that:
1. the opcode is OP_PUSH
2. the argument is a register
3. the register is one of (eax, ebx, ecx, edx, esi, edi)
In BC that'd be:
1. the opcode is a call
i.e.: d.x86_opcode == OP_CALL
2. the argument is an immediate relative value
i.e.: d.arg[0].access_type == ACCESS_REL
Then we pick the call target and we "jump" to it, not before saving the return address:
Another interesting example is the trash code parser. There can be 3 types or trash ops:
2. the argument is a register
3. the register is one of (eax, ebx, ecx, edx, esi, edi)
In BC that'd be:
d.x86_opcode == OP_PUSHAltogether:
d.arg[0].access_type == ACCESS_REG
d.arg[0].u.reg == REG_EAX || d.arg[0].u.reg == REG_ECX || d.arg[0].u.reg == REG_EDX || d.arg[0].u.reg == REG_EBX || d.arg[0].u.reg == REG_ESI || d.arg[0].u.reg == REG_EDI
if(d.x86_opcode == OP_PUSH && d.arg[0].access_type == ACCESS_REG && (d.arg[0].u.reg == REG_EAX || d.arg[0].u.reg == REG_ECX || d.arg[0].u.reg == REG_EDX || d.arg[0].u.reg == REG_EBX || d.arg[0].u.reg == REG_ESI || d.arg[0].u.reg == REG_EDI))Then we need to check for the call $DELTA. In other words we check that:
1. the opcode is a call
i.e.: d.x86_opcode == OP_CALL
2. the argument is an immediate relative value
i.e.: d.arg[0].access_type == ACCESS_REL
Then we pick the call target and we "jump" to it, not before saving the return address:
int32_t target_address, return_address;
seek(cur-4, SEEK_SET); /* we position onto the call argument */
read(&target_address, sizeof(target_address)); /* we read the relative jump value */
target_address = le32_to_host(target_address); /* we handle big endian machines */
retaddr = cur; /* we save the address to return to */
target_address = cur + target_address; /* we compute the addres to jump to */
Another interesting example is the trash code parser. There can be 3 types or trash ops:
A. Arithmetic or logic operation on a stack allocated DWORD based on an immediate or register value. Eg:
1. d.x86_opcode is one of (OP_ADD, OP_ADC, OP_AND, OP_MOV, OP_OR, OP_SBB, OP_SUB, OP_XOR), i.e.:
2. the dest argument is a mem region:
3. the access size is a DWORD:
4. the dest argument is in the form [ebx-displacement]:
5. the displacement fits within the local funcion stack:
6. the source argument can be anything (i.e. a register or an immediate value): nothing to check!
Case B is very similar, except the arguments are reversed:
1. The dest argument is a register:
2a. The src arg is either another reg:
2b. Or it is an immediate:
2c. Or it is a stack based DWORD:
Finally, case C... Here we:
1. Check that the op is a jmp:
2. Check that it's got an immediate argument:
3. Then we can "jump" to the next position:
mov [ebp-xx], immedB. Arithmetic or logic operation on a 32bit register based on a stack allocated DWORD or an immediate value. Eg:
add [ebp-xx], register
mov register, [ebp-xx]C. A jump to the next chunk of code.Eg:
sub register, other_register
jmp next_chunkMore in details, for case A we check that:
1. d.x86_opcode is one of (OP_ADD, OP_ADC, OP_AND, OP_MOV, OP_OR, OP_SBB, OP_SUB, OP_XOR), i.e.:
d.x86_opcode == OP_ADD || d.x86_opcode == OP_ADC || d.x86_opcode == OP_AND || d.x86_opcode == OP_MOV || d.x86_opcode == OP_OR || d.x86_opcode == OP_SBB || d.x86_opcode == OP_SUB || d.x86_opcode == OP_XOR
d.arg[0].access_type == ACCESS_MEM
d.arg[0].u.mem.access_size == SIZED
d.arg[0].u.mem.scale_reg == REG_EBP && d.arg[0].u.mem.scale == 1 && d.arg[0].u.mem.add_reg == REG_INVALID
d.arg[0].u.mem.displacement <= -4 && d.arg[0].u.mem.displacement >= -(int32_t)stacksize
6. the source argument can be anything (i.e. a register or an immediate value): nothing to check!
Case B is very similar, except the arguments are reversed:
1. The dest argument is a register:
d.arg[0].access_type == ACCESS_REG
2a. The src arg is either another reg:
d.arg[1].access_type == ACCESS_REG
2b. Or it is an immediate:
d.arg[1].access_type == ACCESS_IMM
2c. Or it is a stack based DWORD:
d.arg[0].access_type == ACCESS_MEM && d.arg[0].u.mem.access_size == SIZED && d.arg[0].u.mem.scale_reg == REG_EBP && d.arg[0].u.mem.scale == 1 && d.arg[0].u.mem.add_reg == REG_INVALID && d.arg[0].u.mem.displacement <= -4 && d.arg[0].u.mem.displacement >= -(int32_t)stacksize
Finally, case C... Here we:
1. Check that the op is a jmp:
d.x86_opcode == OP_JMP
2. Check that it's got an immediate argument:
d.arg[0].access_type == ACCESS_REL
3. Then we can "jump" to the next position:
int32_t rel;
seek(cur-4, SEEK_SET); /* move onto the jmp argument */
read(&rel, sizeof(rel)); /* read it */
rel = le32_to_host(rel); /* make it big endian safe */
cur += rel; /* "jump" to it */
Blog post by Alberto Wu.
Monday, October 17, 2011
Just released is version 0.97.3 of ClamAV. The following changes are noted in the ChangeLog distributed with the package:
You can download the newest version of ClamAV by visiting the ClamAV.net website, or at the following download links:
Mon Oct 10 14:41:48 CEST 2011 (tk)* freshclam/manager.c: fix error when compiling without DNS support (bb#3056)Sat Oct 8 12:19:49 EEST 2011 (edwin)* libclamav/pdf.c: flag and dump PDF objects with /Launch (bb #3514)Sat Oct 8 12:10:13 EEST 2011 (edwin)* libclamav/bytecode.c,bytecode_api.c: fix recursion level crash (bb #3706).Tue Aug 2 17:03:33 CEST 2011 (tk)* docs: clarify behavior of --scan-*/Scan* options (bb#3134)Mon Jul 25 16:09:19 EEST 2011 (edwin)* libclamav/bytecode_vm.c: fix opcode 20 error (bb #3100)Thu Sep 15 14:44:11 CEST 2011 (tk)* freshclam: fix pidfile removal (bb#3499)Sun Aug 21 17:05:24 EEST 2011 (edwin)* libclamav/pdf.c: fix incorrect blocking of some encrypted PDF with empty user passwords. (bb #3364)Wed Aug 3 15:41:28 CEST 2011 (tk)* sigtool/sigtool.c: fix calculation of max signature lengthYou can download the newest version of ClamAV by visiting the ClamAV.net website, or at the following download links:
Subscribe to:
Comments
(
Atom
)