Tuesday, October 8, 2013

In July we told you about Sourcefire’s agreement to be acquired by Cisco, and today that acquisition has closed – we are now one company. This also means that we are also now one community, and Cisco has reiterated its commitment to maintaining our innovation and support of Snort, ClamAV and other open source projects, as well as its own projects. As Marty Roesch wrote on our corporate blog:
"I can tell you with certainty that this is a great match for Sourcefire, for Cisco and, ultimately, for our customers, partners and open source communities… Beyond the technology, one of the things that is important to me is that Cisco and Sourcefire both share key values that transcend our company names, HQ locations and number of employees."

 I’m also happy to report that there will be no changes to how our communities are run or our communications, including mailing lists, snort.org, clamav.net or social media sites. Please visit the corporate blog for more details and, as always, reach out to me with questions. I will still be your community manager and I look forward to many more years of being a part of this community.

Friday, October 4, 2013

Everyone that reads this blog may not read all of the other Sourcefire/Vulnerability Research Team (VRT) Blogs, so I thought I'd add a quick comment here about one of the Malware Research Teams articles over on our VRT Blog.

The article is entitled "Android Basic Block Signatures" and he goes over some good syntax for the ClamAV Signature Language.

Please check it out here: http://blog.talosintel.com/2013/10/android-basic-block-signatures.html

Thursday, September 19, 2013

ClamAV 0.98 includes many new features, across many different components
of ClamAV. There are new scanning options, extensions to the libclamav API,
support for additional filetypes, and internal upgrades.

- Signature improvements: New signature targets have been added for
PDF files, Flash files and Java class files. (NOTE: Java archive files
(JAR) are not part of the Java target.) Hash signatures can now specify
a '*' (wildcard) size if the size is unknown. Using wildcard size
requires setting the minimum engine FLEVEL to avoid backwards
compatibility issues. For more details read the ClamAV Signatures
guide.
- Scanning enhancements: New filetypes can be unpacked and scanned,
including ISO9660, Flash, and self-extracting 7z files. PDF
handling is now more robust and better handles encrypted PDF files. 
- Authenticode: ClamAV is now aware of the certificate chains when
scanning signed PE files. When the database contains signatures for
trusted root certificate authorities, the engine can whitelist
PE files with a valid signature. The same database file can also
include known compromised certificates to be rejected! This
feature can also be disabled in clamd.conf (DisableCertCheck) or
the command-line (nocerts). 
- New options: Several new options for clamscan and clamd have been
added. For example, ClamAV can be set to print infected files and
error files, and suppress printing OK results. This can be helpful
when scanning large numbers of files. This new option is "-o" for
clamscan and "LogClean" for clamd. Check clamd.conf or the clamscan
help message for specific details. 
- New callbacks added to the API: The libclamav API has additional hooks
for developers to use when wrapping ClamAV scanning. These function
types are prefixed with "clcb_" and allow developers to add logic at
certain steps of the scanning process without directly modifying the
library. For more details refer to the clamav.h file. 
- More configurable limits: Several hardcoded values are now configurable
parameters, providing more options for tuning the engine to match your
needs. Check clamd.conf or the clamscan help message for specific
details. 
- Performance improvements: This release furthers the use of memory maps
during scanning and unpacking, continuing the conversion started in
prior releases. Complex math functions have been switched from
libtommath to tomsfastmath functions. The A/C matcher code has also
been optimized to provide a speed boost. 
- Support for on-access scanning using Clamuko/Dazuko has been replaced
with fanotify. Accordingly, clamd.conf settings related to on-access
scanning have had Clamuko removed from the name. Clamuko-specific
configuration items have been marked deprecated and should no longer
be used.

There are also fixes for other minor issues and code quality changes. Please
see the ChangeLog file for details.

--
The ClamAV team (http://www.clamav.net/team)

Monday, September 16, 2013

As a reminder in case you didn't see the first warning, we are planning on pushing a new Main.cvd tomorrow, September 17th.  This will cause an increase in load on the mirror infrastructure as clients will have to download this new file.

Please see my previous blog post on the matter if you have any questions:
http://blog.clamav.net/2013/09/maincvd-scheduled-for-tuesday-september.html

Wednesday, September 11, 2013

As many of you have written in and notified us, the "Daily.cvd" file is now bigger than the "Main.cvd".  This means on our side, it's time to make a new Main.cvd.

We are currently planning on cutting a new Main.cvd on Tuesday September 17th.  After the new Main.cvd is published the daily load on the mirrors and your networks should be much lighter.

We are estimating the new "Main" to be ~70MB.

We are also planning on making a new Main.cvd more periodically so this can be more easily predicted.  More information about this periodic process will be published as more details become available.

Thursday, August 22, 2013

Douglas Goddard, one of our awesome malware analysts here at Sourcefire wrote a post about Bytecode and it's ability to cover the recent Android Master Key Vulnerability.

Take a look at the blog post here: http://blog.talosintel.com/2013/08/bytecode-covering-android.html

Tuesday, July 23, 2013

A Continued Commitment to Open Source

Earlier today Cisco announced a definitive agreement to acquire Sourcefire. Marty Roesch has detailed the announcement on our corporate blog, but we want to make sure that you, our friends and community, are especially assured of Cisco’s commitment to maintaining our innovation and support of our open source projects. As Marty writes:

“I created Snort in 1998 to provide value-added security solutions for open source and address big problems that no one else could solve. We later expanded that open source commitment to ClamAV… The best news in all of this, especially for our partners, customers and open source users, is that Cisco is committed to accelerate the realization of our vision into the market. We’ll be able to more quickly innovate, develop and provide products and technologies that continue to solve your biggest security challenges. And not just for commercial and government solutions – they are committed to continued innovation and support of our open source projects, too."

Please visit the corporate blog for more details and feel free to reach out to me with any questions that you might have. We look forward to continuing to innovate together.

Additional Information and Where to Find It

In connection with the proposed acquisition by Cisco Systems, Inc. (“Cisco”) of Sourcefire, Inc. (“Sourcefire”) pursuant to the terms of an Agreement and Plan of Merger by and among Sourcefire, Cisco, and a wholly-owned subsidiary of Cisco, Sourcefire will file a proxy statement with the Securities and Exchange Commission (the “SEC”). Investors are urged to read the proxy statement (including all amendments and supplements) because it will contain important information. Investors may obtain free copies of the proxy statement when it becomes available, as well as other filings containing information about Sourcefire, without charge, at the SEC’s Internet site (http://www.sec.gov). These documents may also be obtained for free from Sourcefire’s Investor Relations web site (http://investor.sourcefire.com/) or by directing a request to Sourcefire at: Sourcefire, Inc., 9770 Patuxent Woods Drive, Columbia, MD 21046.
Sourcefire and its officers and directors and other members of management and employees may be deemed to be participants in the solicitation of proxies from Sourcefire’s stockholders with respect to the acquisition. Information about Sourcefire’s executive officers and directors is set forth in the proxy statement for the Sourcefire 2013 Annual Meeting of Stockholders, which was filed with the SEC on April 24, 2013. Investors may obtain more detailed information regarding the direct and indirect interests of Sourcefire and its respective executive officers and directors in the acquisition by reading the preliminary and definitive proxy statements regarding the transaction, which will be filed with the SEC.

Forward-Looking Statements

This written communication contains forward-looking statements that involve risks and uncertainties concerning Cisco’s proposed acquisition of Sourcefire, Sourcefire’s expected financial performance, as well as Sourcefire’s strategic and operational plans. Actual events or results may differ materially from those described in this written communication due to a number of risks and uncertainties. The potential risks and uncertainties include, among others, the possibility that the transaction will not close or that the closing may be delayed; the reaction of our customers to the transaction; general economic conditions; the possibility that Sourcefire may be unable to obtain stockholder approval as required for the transaction or that the other conditions to the closing of the transaction may not be satisfied; the transaction may involve unexpected costs, liabilities or delays; the outcome of any legal proceedings related to the transaction; the occurrence of any event, change or other circumstances that could give rise to the termination of the transaction agreement. In addition, please refer to the documents that Cisco and Sourcefire file with the SEC on Forms 10-K, 10-Q and 8-K. The filings by Sourcefire identify and address other important factors that could cause its financial and operational results to differ materially from those contained in the forward-looking statements set forth in this written communication. Sourcefire is under no duty to update any of the forward-looking statements after the date of this written communication to conform to actual results.

Tuesday, April 23, 2013

Dear ClamAV users,


"ClamAV 0.97.8 addresses several reported potential security bugs. Thanks to Felix Groebert of the Google Security Team for finding and reporting these issues."


Download: http://downloads.sourceforge.net/clamav/clamav-0.97.8.tar.gz 
PGP sig: http://downloads.sourceforge.net/clamav/clamav-0.97.8.tar.gz.sig
ChangeLog: https://github.com/vrtadmin/clamav-devel/blob/0.97/ChangeLog

--
The ClamAV team (http://www.clamav.net/lang/en/about/team/

Monday, April 15, 2013

One of the questions I receive in my inbox quite frequently is:

"Does ClamAV need any more mirrors for virus definitions?"

The quick answer is "Yes!"  We'll take all the mirrors that we can get, as we increase output of virus definitions and such, we need more infrastructure to be able to handle the load.

If you are interested in becoming a ClamAV mirror, please follow the instructions here:

https://github.com/vrtadmin/clamav-faq/blob/master/mirrors/MirrorHowto.md


Friday, March 15, 2013

Dear ClamAV users,


"ClamAV 0.97.7 addresses several reported potential security bugs. Thanks to Felix Groebert, Mateusz Jurczyk and Gynvael Coldwind of the Google Security Team for finding and reporting these issues."


Download: http://downloads.sourceforge.net/clamav/clamav-0.97.7.tar.gz 
PGP sig: http://downloads.sourceforge.net/clamav/clamav-0.97.7.tar.gz.sig
ChangeLog: https://github.com/vrtadmin/clamav-devel/blob/0.97/ChangeLog

--
The ClamAV team (http://www.clamav.net/lang/en/about/team/

Tuesday, February 26, 2013

Certain users are experiencing database update issues due to the failed Authenticode database push. This blog post will show how to check if you're one of those affected users and how to fix freshclam.

Validate You're Affected

You can validate that you're having this particular issue by a number of ways:
  1. Check the hash of your daily.cvd. You are affected if the hash matches the following:
    1. MD5: 89dedb45609e59b0244fb5202ab6fa56
    2. SHA1: 9947ec90e60499ab7c3331670d5b26b4eaac76e4
  2. Check your freshclam log file for repeated errors that look like:
    1. Ignoring mirror [Mirror's IP address here] (has connected too many times with an outdated version)
  3. Check the version number and the functional level of the daily.cvd by using sigtool:
    1. sigtool --info daily.cvd will show a version number of 16681 and a functionality level of 73

How To Fix Freshclam

If you are expereincing the problem, please do the following:  Stop the freshclam daemon if it's running, delete both mirrors.dat and daily.cvd, then restart the freshclam daemon. Freshclam will then download a new daily.cvd and will be up-to-date.

We apologize for any inconvenience this has caused and thank you for using ClamAV.  If you have any further issues, please send a message to the ClamAV user's list or contact us via IRC.

Monday, February 25, 2013

In preparation for the ClamAV 0.98 release, we will be performing maintenance on the infrastructure beginning at 5:00 PM EST on 04 Mar 2013.

We will be pushing out a new signature database that does not have a corresponding cdiff file. This means that clients will pull down a full copy of the daily.cvd database, which will cause an increase in download traffic from the mirrors.

The maintenance is estimated to take one hour.  No impact to users, beyond the downloading of a new daily.cvd, is anticipated.

We would like to extend our thanks to the mirror providers for their contributions, and thank you for using ClamAV.

On Thursday, 14 Feb 2013, in preparation for the coming ClamAV 0.98 release, a new database was scheduled to be made available to users. We had a set of issues while performing this upgrade, and we feel that it is appropriate to let our users and mirror providers know what happened, what has done to fix the issues, and what is being done to prevent these issues from happening again.

So first, What Happened?

  1. 14 Feb 2013 0800 EST: Start of our scheduled work on our infrastructure.
  2. 14 Feb 2013 0815 EST: A new, custom daily.cvd (our virus definition database) was published. This database was generated with ClamAV 0.98, which in turn caused freshclam to think that a new version of ClamAV was available (not yet, but there will be).
  3. 14 Feb 2013 0830 EST: Published a new daily.cvd, generated with ClamAV 0.97.6, the current version of ClamAV. This corrected the issue with incorrect notifications of a new version of ClamAV.
  4. 14 Feb 2013 1100 EST: Clients report errors with updating. Investigation starts.
  5. 14 Feb 2013 1130 EST: The problem was isolated. The new database wasn't copied into a critical directory on our internal Signature server. The database publishing infrastructure didn't know that a custom database had been published. The custom database was overwritten with a new database.  This resulted in some users being unable to use the .cdiff files (our incremental update files) for updating, leading to users who had downloaded the custom database to be unable to update.
  6. 14 Feb 2013 1330 EST: A new database was published to resolve the issues. Issues should now be resolved for most users.
  7. 19 Feb 2013 1700 EST: Issues resolved for all remaining users by modifying the set of available .cdiff files.
Fixes That Have Been Performed

We've deleted all database files that would cause errors. This should fix the remainder of issues for our users.  However, any users who are still seeing errors should delete the mirrors.dat file in their database directory to force a reset of mirror selection.

Prevention

We've put in place a workflow that will prevent issues like this from popping up. A full change-management process is in place, with an emphasis on peer-reviewed planning, comprehensive test plans and appropriate personnel assignments.  Change plans will be approved by a senior administrator, a ClamAV developer and a representative from the analyst team.

For the convenience of our mirror providers, there is now a set maintenance window for routine changes: Monday 5pm EST through midnight EST.  As always, we will aim to notify mirror providers a week in advance of any change.  In the case of emergent issues, a different time or a shorter notification may be required.

We apologize for any inconvenience caused by the problems outlined in this post.  We will continue to review our processes to ensure that we are providing the best experience for both our users and our mirror providers.

Wednesday, February 13, 2013

Introduction

Microsoft introduced digitally signing PE object files (authenticode) in Windows 98. Hardware drivers eligible for the Windows Logo Program are required to contain a valid authenticode signature. Since then, Microsoft has expanded the program to executable object files (EXEs) and DLLs.

Microsoft has its own public key infrastructure (PKI). There are four trusted root certificate authorities: two by Microsoft, Thawte, and Verisign. Microsoft's own executables for Windows are signed.

Authenticode At Work

The Problem

It's becoming more common for malware authors to sign their executables. Malware authors are known to steal existing certificates or forge certificates (the certificate forging link talks about SSL certificates; though you can't use certificates used for web browsing with authenticode, the concept still applies). Stealing and forging existing certificates can trick unsuspecting users into trusting the malware.

The Solution

ClamAV 0.98 now parses and validates the authenticode certificates. ClamAV now ships a database of trusted and revoked certificates. If the PE file being scanned is flagged as a virus, ClamAV follows this logic in validating the certificate chain contained inside the PE file:

  1. Load the chain in full
  2. Validate each certificate in the chain:
    1. If no certificate matches one of the four trusted roots, the whole chain is considered invalid and is subsequently ignored. Further chain processing is stopped.
    2. If one certificate matches a revoked entry in the database, the whole chain is considered invalid. Report PE file being scanned is a virus.
    3. If no certificates match a revoked entry in the database, the PE file is marked as clean. No virus is reported for the PE file being scanned.

Generating A Certificate Revocation Entry

Since the authenticode chain is verified only after a file has been flagged as virus by the ClamAV engine, you have to first create a signature for the file if one doesn't already exist. If a signature exists, yet the file is reported as clean, chances are that the file is being whitelisted due to having a valid authenticode signature. You can verify that the file is being whitelisted by passing --debug --verbose to clamscan and looking for the word authenicode (yes, that is indeed misspelled, but that works out to our advantage). If you see that word, then the file is being whitelisted and a certificate revocation entry needs to be created.

First, we need to dump the certificate chain so that we can find the certificate to revoke. You can tell ClamAV to dump the certificate chain to stderr by passing --dumpcerts to clamscan. You will then match the certificate that is dumped with the public key of the lowest certificate in the chain that Windows shows. Windows shows a few bytes before the public key actually starts. Don't worry, if that confuses you, I have screenshots:

Windows Certificate Information
Validating and Dumping Authenticode Certificate Information via ClamAV

Certificate revocation entries go into a .crtdb file in your ClamAV database directory. Its format is as follows: name;trusted;subject;serial;pubkey;exponent;codesign;timesign;certsign;notbefore;comment[;minFL[;maxFL]]

Where:
  1. Name: a descriptive name for the certificate entry
  2. Trusted: a bit field (0 or 1) whether this entry is trusted or revoked
  3. Subject: the subject reported by ClamAV
  4. Serial: the serial reported by ClamAV
  5. Pubkey: the public key reported by ClamAV
  6. Exponent: The exponent of the certificate. Set this to 010001.
  7. Codesign: A bit field (0 or 1) whether this certificate can sign code
  8. Timesign: A bit field (0 or 1) whether this certificate can generate a timestamp signature
  9. Certsign: A bit field (0 or 1) whether this certificate can sign other certificates
  10. Notbefore: The notbefore field of the certificate. Defaults to 0 if empty.
  11. Comment: any comments about this entry
  12. MinFL: The minimum ClamAV feature level needed for this entry. Required only if MaxFL is set.
  13. MaxFL: The maximum ClamAV feature level supported by this entry
Let's return back to the example. We now have enough information to create the certificate revocation entry. It would look like: 
Descriptive name here;0;fe72355be4b6893d8e5b628d1a9ae8863d202b6f;a58d94ce010afa9865e732870971428768c92d64;ba0532ff862861cfaf8c22601fe479e3697b6ab94ff01c3254d105018c93bdb47f4c3fc1fb1d20172c46a727fb589f310cf6b081517ee472d145dfd4939c7d4652aad06c3ee6722f15703e88bbd8bc4d56fe7030b21f105fa9817b625103273caf46072628207e81bc13ac6ba18cdd3e93b97c9761730eb14ce36464cc997075;010001;1;0;0;0;

After adding that revocation entry to our certs database, ClamAV now flags the sample as a virus:
clamscan Reporting Virus