Skip to content

Securing transfer of Anti Virus policies

This article was been published more than a year ago. The information may be outdated.

Fighting and defending against computer viruses is one of the largest challenges facing businesses and individuals in the IT world of today. To guard against this, most people have anti-virus software installed on their computers. However, even though you have anti-virus software installed, how can you be certain that the policy-files are the ones your anti-virus supplier has supplied? What is done by the different developers to secure the transfer of these files? What sort of knowledge and access would be needed to hack through the protection?
 
I’ve asked these questions to a few of the leaders in anti-virus software development. Only two answered my questions; here’s what they said:
 
Norman

Norwegian security solutions developer Norman, whose security suite was recently crowned the winner in a Norwegian test of anti-virus solutions, could tell us that they have been using more or less the same method since the fall of 1999. Their method entails distributing all their software files as ZIP-archives that have been signed and encrypted by a proprietary algorithm. Once downloaded to the client computer by their program Norman Internet Update (NIU), whereupon NIU proceeds to decrypt the downloaded files.
 
In order to hijack the transfer, three key elements are needed:
 
1. Knowledge of, and/or access to the utility used to encrypt and sign the files
2. Ability to spoof the NIU-client in order to make it download the files from a different site
3. One would also need to hack the protocol used between the NIU-client and the update servers, a protocol encrypted with a separate, proprietary algorithm.
 
Norman has seen many attempts to hack the method since it was employed, none of which have succeeded
 
Sophos

The British anti-virus developer Sophos, that develops security solutions for businesses, tells us they use a different method. They use a secured end-to-end SSL v3.1 2048 bit encrypted tunnel, using a Corba based management methodology. Within the tunnel (which uses pre-verified certificates distributed via the installer) a 512bit key-pair is agreed between server and each client for layered complexity.
 
To hijack the transfer, the following would have to be done: First off, the attacker would need a copy of the certificates shared during installation (denying regular users local administrator access would simply and quickly make this a lot more difficult for an attacker). Secondly, the attacker would need to gain access to the VPN-tunnel (2048 bit), or crack said tunnel if they don’t have the certificate. On top of this, the attacker would need a copy of each of the pre shared keys for each computer, and work out the Sophos-specific implementation to crack the keys assigned to the computer. The entire process would need to be repeated for each computer, as every computer has a different key.
 
Conclusion

In spite of significant advances in the field of computer security solutions, there are still many threats out there, and time has shown, and will most likely continue to show, that there is no such thing as absolute certainty. Because of this, it is imperative that developers of security solutions not only worry about their own end and the computers belonging to their customers, but that they also worry about, and take steps to ensure, the transfers and updates of policies. In spite of limited responses to my inquiries, the answers I have received bear witness that these are problems that are taken very seriously indeed, and the steps taken thus far seem to have been effective.

One Comment

  1. corba server

    […] … or application server vendor decide to extend the CORBA protocol or add non-CORBA calls. …Securing transfer of Anti Virus policies – STFU && RTFMFighting and defending against computer viruses is one of the largest challenges facing businesses […]

Comments are closed, but trackbacks and pingbacks are open.