Recommendations and the Possible Future - Current Trends and Recommendations - The Antivirus Hacker's Handbook (2015)

The Antivirus Hacker's Handbook (2015)

Part IV. Current Trends and Recommendations

Chapter 17. Recommendations and the Possible Future

The current protection levels provided by most antivirus solutions are not as good as one would expect from an industry that deals with security products. This chapter discusses some strategies that the security industry may adopt to increase the effectiveness of its products.

This chapter is meant to give you ideas about how to improve the protection and quality of antivirus products. It will also give you some ideas about what you can and cannot expect from an antivirus solution, starting with some ­general recommendations regarding most antivirus products.

Recommendations for Users of Antivirus Products

An antivirus product is synonymous with security for most users, but this is not completely accurate. This part of the chapter explains some typical misunderstandings and also gives recommendations for antivirus software users, especially those who should be most worried about vulnerabilities in security products: big companies and governments. In any case, most of the recommendations here still apply to other users of antivirus products.

Blind Trust Is a Mistake

Blind trust in the security provided by antivirus software is the most common mistake people make. It is no surprise that messages such as “My computer is infected with malware. How can it be? I have antivirus installed!” continue to appear on public forums.

Before putting all your faith into antivirus products, you should consider the following points:

· Antivirus products cannot protect against mistakes made by users. Attacks that use social engineering tactics cannot be stopped by antivirus software. Users should have some security awareness and training.

· Antivirus solutions are not bulletproof; they have bugs and weaknesses like any other piece of software installed on your computer.

· Antivirus products work by detecting what they know based on the signatures, heuristics, and static and dynamic analysis techniques they have support for. They cannot detect unknown or new threats unless those threats are based on patterns (either behavioral or statically extracted artifacts) that are already known to the antivirus company.

· A key part of the development or quality assurance (QA) phases of effective malware is to actually bypass all or most existing antivirus solutions. In general, this is not especially difficult and is done on a regular basis by both illegal and legal malware (such as FinFisher).

· Antivirus products can be exploited like any other software.

· It is easier to exploit a security product, such as antivirus software, than an Office suite or browser.

· At least one antivirus company (Kaspersky) is publicly known that was owned in a state-sponsored attack (likely launched by Israel): its tools were not useful to prevent the attack.

Users (especially non-technical computer users) often consider antivirus products to be the Holy Grail of security. They view an antivirus product as software that they can install and then simply forget about, because the antivirus product takes care of all security matters for them. This sort of mentality is also encouraged by the marketing campaigns of antivirus products. Campaigns with slogans such as “Install and forget!” are common, but these slogans are far from true and are a serious challenge to real security.

Because of a lack of security education and awareness or because they fell for a social engineering trick, users sometimes disable an antivirus product temporarily to install an application they download from the web or receive by email. While this may sound unusual, it is one of the most common ways antivirus software users become infected. Often, stories ranging from hilarious to tragic can be heard when chatting with an antivirus support engineer about his or her opinion on this subject.

A common social engineering ruse occurs when a certain malware politely asks users to disable the antivirus software because it may interfere with the installer. The malware can also simply ask a user for higher privileges. When the user clicks Yes at the User Account Control (UAC) prompt in Windows, the malware disables the antivirus solution and does anything it wants to do. Many instances of malware, which are sometimes successful, are distributed by an email asking the user to disable the antivirus before actually opening the attachment, be it a document, picture, or executable. As crazy as it sounds, this works.

Many users still falsely believe that an antivirus program knows about every malware and about everything malware can do. However, antivirus solutions are not bulletproof. A bug in the antivirus software may allow a certain piece of malware to slip under the radar and remain undetected, thus leaving the malware to freely roam in the system. For example, a zero-day bug in the antivirus software, or in the actual operating system, can be leveraged by the malware so that it can do whatever it needs to do to complete its infection, often from kernel-land.

It is important to know that malware research and new infection and evasion techniques advance much more quickly than the defense and detection mechanisms that antivirus researchers create. Therefore, an antivirus product may know nothing about the new techniques that an advanced malware product is using until a sample is captured in the wild and is sent to the antivirus companies for analysis.

Antivirus software can only protect against what it knows of. New malware, or even old malware, can simply morph its contents to evade the static detection signature that one or more antivirus products use. For example, a new executable packer or protector can be used by malware (or goodware!) authors to evade detection. Using an executable packer to change the layout of executable malware while keeping its logic intact is not as complex as it sounds; sometimes it is as simple as packing the malware to render it statically undetectable.

An antivirus product still has some chance to detect malware by using dynamic analysis techniques while the malware is executing. For example, the antivirus program may monitor the process by using some kind of API hooking. If API monitoring is done in userland, the malware can simply remove the hooks, as I discussed in Chapter 9. If API monitoring is done in kernel-land, the malware can perform the monitored actions with long delays between them, so the kernel-land monitoring component “forgets” about previous actions; this is a common technique used in many malware products. This approach confuses behavior monitoring and heuristic engines in antivirus solutions. Malware can also use inter-process communication to distribute malicious tasks between its various components; this, too, can throw off the behavior-monitoring engines. Most antivirus products know nothing about what the malware is doing in such cases.

Also keep in mind that malware development uses the same cycles that any other software development uses; that is, QA is an integral part of effective malware. For example, malware kits offered on the black market usually come with a support period. During that time, malware kit updates are provided to buyers. One of the typical updates supplied for such software is actually related to antivirus evasion. Indeed, before release, a new piece of malware—depending on its quality—is likely to be beta-tested against the most common antivirus solutions. Therefore, when the new malware is released, the malware authors know that antivirus vendors will know nothing about it until they get the first samples, analyze the malware, and develop the detection (and possibly disinfection) code. The malware will eventually be detected by antivirus vendors, and so the malware writers will update the product to evade detection by antivirus products. Again, the antivirus vendors will update their products with new signatures to detect the new version, and so on. This is the infamous cat-and-mouse game that you hear about in the software security industry. Unfortunately for computer users, malware authors are always one step ahead, regardless of what the antivirus industry advertises.

In previous examples, I focused mainly on malware that was distributed on a massive scale. Targeted malware can go unnoticed for the entire time that the malware attack is underway. Once it has accomplished its objective, it is removed and, like magic, nobody notices anything.

It is also important for users to understand that antivirus products can be owned just like any other software and that the security measures they implement are much simpler—if they exist at all—than the security measures implemented in Office suites or browsers, such as Microsoft Office or Google Chrome. This means that the antivirus solution you are using can actually be the entryway to your computer. For example, malware can exploit a bug in a file format parser. The protections implemented in the antivirus software for preventing exploitation in the actual antivirus are frequently non-existent or rudimentary at best. For example, in one “self-protection” mechanism, the antivirus software prevents calls such as ZwTerminateProcess over one of its processes.

Consider the following hypothetical, but very possible, scenario, where an antivirus can be owned and trojanized so that it hosts the malware:

1. A malware is executed in the target's computer.

2. The malware uses a zero-day mechanism to disable the antivirus program. A DoS bug, triggered by a null pointer access that crashes the antivirus service, is more than enough.

3. While the antivirus software is still restarting in order to recover from the crash, the malware Trojanizes some components of the antivirus program. For example, it may drop a library in the antivirus program directory that will later be loaded by the userland components of the antivirus software.

4. The malware, after it properly deploys itself, restarts the antivirus program if required.

5. Now the malware is actually running within the context of the antivirus product.

Here is another even more probable—and more worrisome—scenario:

1. An exploit is executed in the target's computer, for example, by taking advantage of some vulnerability in a web browser. The exploit then downloads and runs some malware.

2. The malware uses a zero-day strategy against the antivirus program in order to execute code in its context (which is running as SYSTEM in Windows or as root in Unix variants) to get out of the browser's or document reader's sandbox.

3. The malware now has elevated privileges and is outside of the sandbox (as antivirus products don't usually run inside a sandbox). The malware can persist in a stealthy manner, often by Trojanizing the antivirus software or by creating and running from a thread in the context of that application.

4. The malware is now successfully running in the context of a privileged application: the antivirus program.

In these situations, do you think the antivirus product does anything to validate itself (its files or its running threads)? It makes no sense, right? After all, how can an antivirus not trust itself?

There are different variations of the same approach:

· Malware can use a zero-day approach to create a thread in any or all of the antivirus programs running as SYSTEM, while communicating between individual threads as a single distributed malware. The antivirus program excludes all of its own processes from the analysis, and so the malware goes undetected.

· Malware can hide as a (non-signed) component of the antivirus program. It can be, for example, a malicious update file or a script inside the program's directory in Unix, such as a cron task script. Because the task script is an antivirus component, it is usually excluded from the analysis.

There are countless ways that malware can use an antivirus product to hide itself. This stealth technique can be considered as an antivirus-level rootkit. Such a rootkit has access to all resources that the antivirus product has, which means it can do virtually anything because it is running in the context of the antivirus application. Also, detecting it will be extremely difficult for the antivirus solution: the antivirus product logic would have to stop trusting even its own files and processes!

I need to point out that I have only seen this approach in a few situations, and then by chance. On one occasion, the malicious code was part of a Metasploit meterpreter stage that was pivoting over antivirus processes (creating threads that jump from process to process) because they were not protected for some reason; on another occasion, the malicious code was hidden in a thread injected by malware in the context of an unprotected application running as the current user. While I have not often seen this approach in my research, it does not mean that it is not possible to have such a stealth mechanism; actually, you can expect the use of advanced stealth techniques from effective malware. This area has probably not been thoroughly researched by many malware authors. It is rare for security researchers to be the first to discover a technique; usually the researcher is simply the first to make such techniques public.

In short, you should never blindly trust your antivirus program. It can be owned, and it can be used to hide malware or a malware process or thread. Blindly trusting your antivirus software can be a big mistake for your organization. I cannot stress this point enough.

Malware Attacks That Do Not Depend on Zero-Day Processes

Some of the scenarios discussed in this section about not trusting an antivirus program can be explained without even using zero-days. For example, say that a file infector, a virus, infects a computer. Every executable that is scanned or executed will be owned before actually executing or opening that file. This happened with the well-known viruses Sality and Virut. How can you trust that the antivirus scanner, which is a normal program, is not going to be infected while it scans files to disinfect them? Even if the antivirus scanner protects itself from being infected as it scans all the files in the computer (which is not that common when an independent command-line scanner is launched), the other executable files may still become infected by the virus. (Of course, whether infection occurs depends on the quality of the disinfection routines of the antivirus.)

A sophisticated file infector can create very different generations for each infection. If you talk with any technical support person who deals with antivirus products, you will discover this is a fairly common situation. However, it can be easily fixed: the scanner and the beta-quality virus database files are copied to a CD-ROM, and then the tool is executed from the CD-ROM. Because the CD is read-only media, the file infector cannot infect it. Problem solved.

Isolating Machines Improves Protection

For big organizations, when possible, I recommend isolating the machines that perform network analysis with antivirus products. The problem is that an antivirus program can be used as the entry point to penetrate your network, and it can also be used as the glue to connect to other internal networks, by helping an attacker to own network analysis security products.

Here is a simple and worrisome example that illustrates how dangerous a not-so-good antivirus solution can be:

1. The perimeter of a targeted organization is heavily protected, with only the email and web servers open to external interfaces. All patches have been applied.

2. The web or email server (or both) scans every file that is received.

3. One of the intercepted files is actually a zero-day exploit targeting the antivirus program that is used by the organization. It is weaponized so that it owns the email gateway or the web server.

4. The attacker successfully penetrates the organization's network by, ironically, taking advantage of the security product it relies on.

5. If the antivirus software performs network analysis on other parts of the network, the attacker can send files (via HTTP, SMB/CIFS, or another protocol) from the owned email gateway or web server to other parts of the network, to penetrate more deeply into the network.

6. If the computers on the network use the same security product, as long as the owned components have network access to these security products and they perform network analysis, they can also be owned with the same zero-day exploit.

Bottom line: when one or two zero-day exploits are used against the antivirus product, the entire organization can be owned. Think about a worm exploiting just one zero-day vulnerability in your favorite antivirus program. While there are no known worms that target antivirus programs, one could definitely be developed.

This scenario applies not only to file analysis tools (such as a common desktop antivirus program) but also to network analysis tools (that is, software that performs analysis of everything flowing through your network). With network analysis tools, the remote attack surface becomes very wide, as these tools have to deal with complex network protocols such as HTTP, CDP, Oracle TNS, SMB/CIFS, and a plethora of other protocols. If the odds of having vulnerabilities in the code of file format parsers are high, the odds of having vulnerabilities in the code performing network analysis are even higher. If you consider the remote attack surface that both components expose, you may think twice about relying on that antivirus solution that was never audited.

Auditing Security Products

Performing an audit of the security product that you want to deploy in your organization—or that you already have deployed—is one of the best recommendations that can be made. You cannot be sure about the quality of the antivirus solution and the real attack surface exposed, or their self-protection levels (if they have any), without relying on your own audits or on audits performed by third parties. It is sensible not to trust the advertisements of security product vendors because it is their job to sell the products.

Although the code of big companies, such as Microsoft, Google, IBM, and Oracle, is frequently inspected by third-party auditors, a lot of antivirus software is never audited. Yes, that's right: never. One of the reasons for this, believe it or not, is that they are very wary of giving their source code to a third party. Third-party auditors are allowed to connect to machines in their headquarters with all the code only in the presence of a staff member who monitors what the auditors are doing. Even so, antivirus vendors should at least perform a black-box audit, often called a binary audit. Unfortunately, most antivirus vendors never audit their products, not even during the development cycle. There are exceptions to this rule; some antivirus companies perform one or many of the following audit types:

· Regular binary audits

· Regular, internal source audits

· Regular source audits by third parties

In my experience, an unaudited application is a buggy application. You can audit your favorite unaudited antivirus program and test this assertion.

Recommendations for Antivirus Vendors

Over about a two-year period, I performed audits on many antivirus products. The sad results were that out of 17 antivirus products, 14 were vulnerable. Usually, after I discover a vulnerability, I exploit it or, at the very least, figure out how it could be reliably exploited.

I also observed that privilege separation, sandboxing, anti-exploiting techniques, and so on are not applied to most antivirus products; this makes it trivial to exploit security applications compared with how complex it is to write an exploit for Google Chrome or Microsoft Word, software programs that implement many top-notch tricks in order to make exploitation more difficult.

The following sections contain some recommendations for the antivirus industry. Some of them likely represent the future of antivirus products, following the logic that was implemented with client-side applications such as Adobe Acrobat Reader, Microsoft Word, and most existing web browsers.

Engineering Is Different from Security

An antivirus company needs good engineers to develop its products, as well as good programmers, analysts, and database, system, and network administrators. However, it also needs security specialists. An antivirus engineer with a number of years of experience in C or C++ does not necessarily have experience writing security-aware code or know how to find vulnerabilities and exploit them. Indeed, some engineers do not have a clue about what security-aware code means, regardless of whether or not they work for a security company.

This problem can be fixed by contracting security engineers and applying the following “magic” trick: training. Training your programmers in security-aware coding, vulnerability discovery, and exploiting will make them more aware of weaknesses or vulnerabilities in the part of the antivirus they develop and will likely result in many vulnerabilities being fixed during the development process. Also, developers with this knowledge will refuse to introduce code patterns that may lead to undesirable conditions. Not implementing this security awareness in your organization will result in coders doing their job without considering the security implications of a design choice or code, because they simply will not have any knowledge about security considerations.

Exploiting Antivirus Software Is Trivial

Sadly, some of the biggest antivirus products, with only a few exceptions (which shall remain unnamed), do not implement the following measures that are typically found in web browsers and document readers:

· Privilege separation

· Sandboxing

· Emulation

· Not trusting other components, by default

· Anti-exploitation measures inside their own products, not only for protecting third-party applications

Most antivirus solutions have an application with high privileges (local system or root) running as the malware analysis service (files and network packet scanning) and a (usually unprivileged) GUI application that shows the results. With only one attack, a maliciously crafted network packet or file, intercepted by the scanner, can cause the service to become owned by exploiting a vulnerability within it, and the exploit will have full privileges, either local system in Windows or root in Unix-based operating systems.

On the other hand, some document applications or web browsers implement privilege separation in a more intricate way. Usually, there is one process with the privileges of the logged-in user and many other worker processes with fewer privileges that actually perform the parsing and rendering of the PDF file, Word document, or web page. If a vulnerability is exploited in that application, the exploit also needs to escape the sandbox to execute code with higher privileges. In the antivirus industry, only a small number of products implement anything similar to this. This situation should change, as it is ironic that a security product is less security-aware than, for example, a document reader.

Perform Audits

The best recommendation I can give to antivirus vendors is to regularly audit their products. You cannot have a secure product without auditing it. Here are the possible auditing choices that you can make:

· Internal audits—These audits should be performed every time a new feature or component is added to your antivirus software.

· Third-party source code review audits—This is the best approach to auditing your application. A third party auditing your company is not biased about which components should be considered, a problem that is common with internal audits. A third-party company analyzes all components and focuses on the more dangerous components without any bias, whereas in-house auditors may look at a piece of code and dismiss it because it has been running without problems for ages and must, therefore, be bug-free.

· Third-party binary audits—These are better than internal audits but less effective than third-party source code reviews. The auditing company will find vulnerabilities in your products using a black-box approach, thus minimizing the risk of the antivirus solution source code being leaked.

Regularly auditing your security products will undoubtedly result in their being more resilient, as long as all the logical recommendations made by the auditors are applied, and the bugs discovered during the audits are fixed.

Fuzzing

Fuzzing (discussed in Chapter 13) is a black-box technique used to discover bugs in a software application. I highly recommend that you continuously perform fuzzing of your target application in order to discover and fix bugs during all the development stages. Fuzzing can be used by developers to test a new feature while coding it. It can also be used by your QA team to probe the final code builds prior to shipping. However, fuzzing should also be used to discover bugs in a released application because some complex bugs appear only after weeks or months of fuzzing.

Fuzzing gives good results, kills most of the obvious bugs in your application, helps you discover some complex ones, and is cheap to implement. Even a single machine using radamsa mutators and running your scanner against the mutated files may work. However, writing something more complex and customized specifically for your product would naturally be better.

Use Privileges Safely

Most antivirus services and processes run with the highest possible privileges, local system or root, and do not use sandboxing or any kind of isolation of components, as web browsers, Office suites, or document readers do. Techniques for making exploitation more difficult, such as the isolated heap or the “Delay Free” recently added to the latest versions of Internet Explorer, are not implemented by a single existing antivirus product. (Or, at least, I failed to find a single one after researching 17 products over two years.)

If the antivirus industry wants to go forward and write effective security software, not cute GUI applications with a label in big capital letters saying “SAFE,” then it must follow the path that popular client-side applications, such as web browsers and document readers, followed years ago. At the very least, it needs to incorporate privilege separation and sandboxing.

Some antivirus companies argue that the antivirus services must execute with high privileges. This is partially true: a mini-filter driver is required to intercept network traffic; a privileged application is required to read and write all files to the disk or even the Master Boot Record (MBR). However, that privileged application's only purpose should be to read a file or packet. The read content should then be sent to another low-privilege application that executes the potentially dangerous code that deals with parsing network protocols or file formats. This would be easy to implement and would require at least two exploits in order to achieve code execution during an attempt to attack antivirus software:

· One exploit to execute code in the context of the low-privilege application doing a file or network packet's parsing

· Another exploit to escape the sandboxed application that is owned

Potentially unsafe code can be made to run in some sort of virtualized or sandboxed environment. For example, an application would not really be running natively but be running inside an emulator or virtual machine. In this case, a successful attack leading to code execution in an antivirus product would require one exploit to escape from the virtual machine prior to trying to escape the sandboxed application. It would make exploitation of antivirus products really complex.

Reduce Dangerous Code in Parsers

The parsers for both file formats and network protocols in an antivirus product are quite dangerous because, by nature, they deal with hostile code. Such code should be written with extreme care because the way this code is written can open a big attack vector. Also, such code should run in sandboxed processes, as previously discussed, because the odds of having exploitable vulnerabilities in C or C++ code, the de facto language for antivirus kernels, are very high. Therefore, instead of writing everything in C or C++, programmers could divide the code base (and responsibilities) between native code and other memory-safe languages, which would mitigate the side effects of writing dangerous and potentially buggy code.

For example, the kernel filesystem filter driver that is used to provide real-time protection in antivirus software does not have to include the file format or protocol parser code; instead, the driver can send a message to a low-privileged (or even sandboxed), managed process (or service) that deals with the file format and then sends the result back to the filter driver.

Managed (memory-safe) or scripting languages such as .NET, Lua, Perl, Python, Ruby, and Java can be used to write detection and disinfection routines and file format and network protocol parsers. The odds of introducing remotely exploitable vulnerabilities with such languages will drop dramatically, and the performance gap between C or C++ code and memory-safe languages will become smaller every year.

In fact, .NET and Lua are actually used by some existing antivirus products. For a vulnerability researcher, using memory-safe languages would really make a difference, as finding security vulnerabilities in memory-safe languages is more difficult because the possibility of introducing a remote vulnerability in such languages is smaller.

Improve the Safety of Update Services and Protocols

The vast majority of antivirus products, sadly, do not use Secure Sockets Layer (SSL) or Transport Layer Security (TLS), which means that everything is downloaded via unencrypted communication channels that can be tampered with by malicious actors. At the very least, all antivirus products should move to implement TLS for all their update services: for downloading programs, as well as for their malware signature database files.

A good example of how to properly implement an update system is the Microsoft Windows Update service. In general, Microsoft uses TLS (HTTPS) for anything that can be dangerous (modified in transit), except for downloading the program files to be updated. This exception may look like a bad decision; however, every single downloaded cabinet file (.cab) or executable is signed and verified by the update client upon delivery.

This well-implemented update service provides another idea about what should be done: all files that are downloaded through an update service must be signed and verified before processing. You may be surprised to discover that most antivirus suites do not sign their virus database files or even programs (this is especially true for their Unix versions) and that they use MD5, SHA1, or CRC32(!) for the sole purpose of verifying that the updated files are transmitted correctly. This approach considers corruption, but it does not consider the update integrity and source. Using RSA to sign the downloaded files or their hashes is more than enough, because not only does it validate their integrity, but it also authenticates the files (checks whether a file's signature is wrong, the file is corrupted, or the file was modified during transit by a malicious actor). If the signature is okay, you can be sure that the file is the original one coming from your servers and that it was not modified.

Remove or Disable Old Code

The amount of old code supporting MS-DOS-era executable packers, viruses, Macro viruses, and a worm for Office 97 is really big. Indeed, the older the antivirus company gets, the greater the amount of obsolete code that is included in its antivirus products. One has to consider that this old code was written during an era when nobody wrote security-minded code, mainly because there was no need at that time. What that means for hackers is that such old code, not touched in more than 10 years, is likely to have vulnerabilities. Such code paths are not commonly exercised, but a vulnerability researcher can find vulnerabilities in this code. I actually discovered some vulnerabilities affecting detections for the old Zmist virus, which was created by the infamous 29A group, as well as in code that was handling very old executable packers. For antivirus writers, I recommend the following:

· Remove the code that is of no use today. Most Windows installations are 64-bit nowadays, and old 16-bit code does not run anyway, so what is the point of keeping detections for old MS-DOS viruses or 16-bit Windows?

· Make old code and detections optional. Perhaps at installation time, the installer can dynamically disable old detections if applicable.

These two simple recommendations can help reduce vulnerabilities. Generally speaking, less code (that is of no use today) means fewer possible vulnerabilities.

On the other hand, removing such code can cause the antivirus product to score lower in some antivirus comparative studies. Some antivirus comparatives, which shall remain unnamed, contained virus databases with such dated malware at least five years ago. While I was working for one antivirus company, I suffered the pain of having to modify an MS-DOS virus detection routine that was buggy and was discovered by using the antivirus comparative's supplied malware database. If your company, after removing obsolete detections, scores lower in a given antivirus comparative, you should consider whether that antivirus comparative is meaningful at all. Some of them are best avoided if your company is more focused on technology than on marketing, because many antivirus tools are purely a marketing stunt with no real value to add on top of the quality of the antivirus product.

Summary

This chapter concludes the book, and with it I share my thoughts and experience on how antivirus vendors could use the knowledge from all the previous chapters to improve their security suites and antivirus software before it is released to the public.

Let's recap the suggested improvements:

· Writing secure code and leveraging programmers with security training—Software engineering is different from security. It does not matter if AV developers are excellent at programming. Without secure programming concepts in mind, programmers are likely to produce a product is prone to various attacks from hackers.

· Perform regular security audits—This is one of the best recommendations I can give. Have security engineers audit the code internally after the developers have done their jobs. Even better, get a third pair of eyes and hire external auditors to take a look at your source code as well; you may be surprised at what they can still find.

· Fuzzing—This topic and its importance were thoroughly discussed in Chapter 13. In short, make fuzzing an integral part of your security testing and QA process in order to discover and fix bugs during all the development stages.

· Use sandboxing techniques—Unlike most modern web browsers, not all AV software employ sandboxes. Since you cannot ensure the safety of your code, it is highly advisable to use sandboxing techniques around code that tends to deal with untrusted input such as network packets, email attachments, and files.

· Use privileges safely—Remember to set and use ACLs on system objects and files properly. Also avoid using high privileges when not needed. Chapter 10 discussed many cases where not setting or incorrectly setting privileges can lead to privilege-escalation kinds of bugs.

· Reduce dangerous code in parsers—This boils down to using proper software design, writing secure code, and doing regular code audits. Additionally, while designing your software, choose to delegate the execution of potentially dangerous code that deals with parsing file formats to sandboxed processes or ones with low privileges. Similarly, if you can, offload complicated file format parsing tasks from kernel-mode drivers or system services to sandboxed user-mode processes. Use interpreted languages or managed code if you can too.

· Improve the safety of update services and protocols—In short, validating the contents of transported files alone is not enough. It is important to use secure transport channels and proper cryptographic techniques to ensure the validity and integrity of the updated files. This topic was thoroughly covered in Chapter 5.

· Remove or disable old code—AV software keeps growing with time. New detection and disinfection routines are added frequently, and then that code is most likely left unmaintained and potentially riddled with unsafe code. Think of the disinfection routines written more than 10 years ago. Back then, secure coding principles were not as widespread as today, and therefore attackers can use old and modified samples to try to break the antivirus.

With the previous points in mind, you should remember that the responsibility does not lay 100 percent in the hands of the AV vendor. There are things that you, as an individual or a company, should take into consideration and some measures to employ to improve the security of your computers:

· Blind trust is an error—As mentioned in Chapter 1, in the section titled “Typical Misconceptions about Antivirus Software,” AV software is not a bulletproof security solution and should not be taken for granted as being synonymous for security. It has its weaknesses just as any software does. Apart from security bugs, AV software cannot protect against mistakes made by users, such as falling for social engineering tactics. Users (especially non-technical computer users) often consider antivirus products to be the Holy Grail of security.

· Antivirus products generally work by detecting what they know based on the signatures, heuristics, and static and dynamic analysis techniques they have support for—They cannot detect unknown or new threats unless those threats are based on patterns (either behavioral or statically extracted artifacts) that are already known to the antivirus company. Part II of this book is solely dedicated to prove that point.

· Malware research and new infection and evasion techniques advance much more quickly than the defense and detection mechanisms that antivirus researchers create—After all, as the saying goes: “It is easier to destroy than to build.”

· To improve protection, consider isolating the machines that perform network analysis with antivirus products—The last thing you want is to have the attacker using the AV software as an entry point to penetrating your network. A bug in the AV's email gateway or firewall, for instance, can be the ticket into your network, where the attacker may move laterally in your network and start targeting computers with high-business-impact (HBI) data.

In conclusion, the field of computer security is always growing, and the future holds many good promises. It is outside the scope of this book to discuss the new security technologies, but for now, you should tread carefully and choose your security solutions wisely.

We hope you enjoyed and benefited from reading this book as much as we enjoyed writing it.