The Antivirus Hacker's Handbook (2015)

Part I. Antivirus Basics

Chapter 5. The Update System

Antivirus software is updated more often than most types of software on your computer. Every couple of hours, or at least once a day, new virus definition files are released by AV companies and downloaded by customers in order to protect them against the latest threats.

All modern antivirus software implements some sort of auto-updating feature. The components that are updated include the core kernel files, signature files, GUI, tools, libraries, or other product files. Depending on how the AV product is configured, automatic updates occur from once to several times per day. The antivirus update strategy depends on the frequency of the update requests. For example, a daily update usually involves pushing daily signatures to the clients. On the other hand, a weekly update involves a big revision download that updates a number of stable signatures.

These update rules are not set in stone, because sometimes when an update is performed, the entire set of signatures and plug-in files is changed. The size of the updates and the components that are updated depend largely on the plug-ins and signature schemes used: if the AV company uses a container for plug-ins and signatures, the entire container is downloaded each time the antivirus is updated. However, if the company distributes each component separately, only the modified components are downloaded.

This chapter discusses the various update protocols that are implemented by antivirus companies and their shortcomings and continues to explain how to dissect an update protocol. This concludes by commenting on how the current methods of HTTPS inspection solve one problem but bring about many other problems.

Understanding the Update Protocols

Each antivirus company, and sometimes each antivirus product, uses a different protocol, updating strategy, signature and plug-in distribution scheme, and so on. However, there are some commonalities between all the update protocols that are listed here:

· They use HTTP or HTTPS (or both) for downloading signatures—In some rare cases, FTP has been observed (mainly in obsolete or old products).

· They include catalog files—The list of downloadable files and remote relative URIs or full URLs is available in one or more catalog files. Such catalog files may contain information about the supported platforms and different product versions.

· They verify the downloaded files—The downloaded update files are usually verified before the old files are updated. Although each antivirus product goes through a verification process, they do so in very different ways, from using simple CRC checks (Cyclic Redundancy Checks) to RSA (a public key-based cryptosystem) signatures.

The following hypothetical antivirus update protocol shows you how a typical update might work:

1. The AV product regularly retrieves (for example, once a day) a file from the web via a URL such as http://av.com/modified-date. This file contains meta-information about the availability of updates.

2. The AV client remembers the last time it was updated, and if the date inside this file is more recent than the last time the antivirus was updated on the client's machine, a catalog file with the list of all available update files is then downloaded from a URL such ashttp://av.com/catalog.ini.

3. The catalog file, whether it is in XML format or simple old INI format, is usually divided into sections for each product, supported platform, and operating system (such as Windows 7 x86_64 or Solaris 10 SPARC). Each section contains information about the files to be updated. Most commonly, this information includes the name of the files to be updated and their hash (for example, MD5) for integrity verification later on.

4. If the MD5 hashes of the files in the update catalog corresponding to the client's files are different, these files are downloaded to the computer.

5. The MD5 hash of the downloaded files is checked to verify that no error occurred during the transmission.

6. If the files are correct, the required services are stopped, old files are moved to a backup directory, new files are copied, and the services are restarted.

This hypothetical protocol resembles how many real-world antivirus update engines work. You will see more concrete examples in the following sections.

Support for SSL/TLS

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are cryptographic protocols designed to provide security over a communication channel such as the Internet (WAN) or an intranet (LAN). They use X.509 certificates (asymmetric cryptography) to exchange a random session key, which is used for symmetric encryption and decryption of the subsequent traffic. SSL protocols are used for online banking and other sensitive information exchange purposes. Using such secure communication protocols is a basic requirement when implementing an update protocol, especially when talking about security software such as antivirus products, but, unfortunately, they are not typically used. The most typical protocol used for downloading updates, as explained in the previous section, is plain old Hypertext Transfer Protocol (HTTP), not Hypertext Transfer Protocol Secure (HTTPS), the version of HTTP implemented on top of SSL/TLS. The use of HTTP in most update protocols opens the door to a wide array of possible attacks:

· If an attacker can change a DNS record, for example, the client will connect to the wrong IP address and download all the files there, without verifying that the server is actually the one the client tool expected, as certificates are not used in HTTP.

· If an attacker can launch a man-in-the-middle (MITM) attack in, say, a local area network (LAN), then the attacker can modify the files (and their hashes in the catalog file) during transit and supply bad copies of files or Trojanized versions of the antivirus products to the client machines.

Recent antivirus products rely on insecure or unencrypted protocols based on HTTP for various reasons. The following are the most common ones:

· Simplicity—It is easier to write a protocol based on HTTP than by using HTTPS properly.

· Performance—Downloads using HTTP are always faster than using HTTPS because the overload of the SSL or TLS layers is removed. Although the performance penalty of using SSL or TLS today is negligible, the first versions of some antivirus products were written one or two decades ago. At that time, perhaps, it was considerable time. Today, however, its negligible.

· Poor coding or programming skills—As simple as it sounds, some antivirus engineers and designers are not security-conscious coders, or they do not properly understand the security requirements of a protocol engine. As such, some antivirus companies implemented the first updating protocol they came up with and continued to use that protocol for many years, even when, in some cases, such protocols where designed at the end of the 1990s or the beginning of the 2000s.

You may have noticed that the word properly is used in the previous list just to emphasize the fact that sometimes the simple solution is implemented rather than the correct one, which is, by the way, a bad practice. Many people, some software developers and designers included, believe that they only need to add SSL/TLS support to their protocols, and they often implement it in an uninformed way by using such transports without considering the security implications. As a result, you can observe the following discrepancies:

· Using SSL/TLS without verifying the server's certificate—This is one of the most typical errors: developers add secure transport capabilities but not the code to check the identity of the server. This is as bad as not using SSL/TLS with the added performance penalty of using such transports. Web browsers such as Google Chrome and the security product EMET from Microsoft provide certificate pinning to validate the identity of the web server.

· Using self-signed certificates—A company may use a self-signed certificate for identifying its update servers, rather than a certificate signed by a known certificate authority (CA), and the certificate may not be added to the client's trusted certificate store. In this situation (as in the previous case where the check code is missing), the client will accept any self-signed certificate that looks like the one it expects. In short, this is as bad as the previous case. Also, because of the way they work, self-signed certificates cannot be revoked; so, if attackers gain access to the private key of the AV company, they can continue performing MITM attacks as long as the certificates installed in each client machine are not revoked. However, certificates signed by a CA can be revoked after such an incident, which makes them invalid. Any new certificates will be automatically accepted because they are signed by a known, trusted CA.

· Accepting valid but expired certificates—A certificate expires after some time. If nobody notices it at the correct time because people are busy or because of bureaucratic shortsightedness, the certificate may expire, causing the clients to refuse to download updates. Because of this, expired certificates are sometimes allowed.

Verifying the Update Files

One of the points where most AV products fail is when verifying downloaded update files. After all, the verification process is reduced to the following steps:

1. Download (likely via HTTP) a catalog file containing the list of files to download and their corresponding hashes.

2. Download relevant files mentioned in the catalog file.

3. Verify the hash of the downloaded files.

The verification of the hash is usually made by comparing the MD5 or SHA1 hash of the downloaded file with the corresponding hash in the downloaded catalog file. In some extremely rare cases, they can even use a CRC32 checksum instead of a cryptographic hash, as when an old, critical vulnerability was discovered by Joxean Koret in the Dr.Web antivirus products. (This bug is discussed in detail in Chapter 15.) Verifying the downloaded files against the hashes stored in the catalog file is the right approach. However, there is a drawback: what if the catalog file containing the hashes is modified by the attacker? The attacker would then be able to modify the transmitted files while also updating the hashes in the catalog file. Doing so does not upset the AV update protocol because the hashes of the downloaded files match the expected hashes. In a typical scenario, the attacker controls the update server and starts serving the modified malicious updates. Not a good situation.

In some rare cases, antivirus products properly implement the verification and integrity of the updates by employing signing algorithms (for example, using RSA). Signing is also used for validating that the files were created by the corresponding developers and were not manipulated during transit. Signing can be applied to executables and sometimes script files. For example, Microsoft signs every .CAB file (an archive file format) downloaded using Windows Update (the protocol used to update Microsoft Windows Security Essentials) and also requires that driver files (.SYS) are signed on x64 platforms before they are loaded by the OS. If a signing mechanism is used, then even if insecure protocols such as HTTP are used, the authenticity of the files is not jeopardized because the attacker would need to craft a binary with a valid signature. This is far from trivial and may be downright impossible without also stealing the certificate from the signer or somehow reconstructing the private key. This has happened in the past, with the Flame malware—probably a state-sponsored piece of malware—which was signed with the attackers' certificate that was generated based on a Terminal Server licensing server certificate with the help of an MD5 collision attack.

Signing and integrity checks are slowly being adopted by most major antivirus products. However, in most cases, the adoption is limited to the Windows platform. Many antivirus products do not sign ELF or MachO executables or the shell scripts used to start their daemons in their Unix version of the products. There are some exceptions, but they are just that: exceptions.

Note

Signing executable files is a common function, at least in Windows operating systems. Signing shell scripts may seem strange at first; however, in Unix, a shell script is just an executable program, similar to a *.VBSscript in Windows. For that reason, scripts should be treated as executables and thus be candidates for signing as well. The usual approach of various AV companies to signing script files is to add a comment line at the bottom of the file containing the RSA signature of the script content (excluding the signature line at the end of the file). For binary files, signatures are usually added as overlay data, at the end of the file. The addition of the signature's bytes is harmless, as the programs reading the files simply ignore the data past the end of the original file. Windows supports binary signing using its Microsoft Authenticode technology.

Dissecting an Update Protocol

This section looks at a real update protocol used by a commercial antivirus product: Comodo Antivirus for Linux (version 1.1.268025-1 for AMD64). For this experiment, all you need are some standard Unix tools (such as grep), Wireshark (a network protocol analyzer, or sniffer, for Unix and Windows), a web browser, and the Comodo antivirus software. You can download the software from https://www.comodo.com/home/internet-security/antivirus-for-linux.php.

Once you have installed the software, you can start playing with it. Antivirus software can use two different types of updates: the software update and the signatures update. The former refers to the scanners, drivers, GUI tools, and so on, and the latter refers to the generic routines for detection and disinfection, as well as the files with the usual CRCs, MD5s, and other signatures. If you run the main GUI in Comodo (with the command /opt/COMODO/cav if it is not already open) for the Linux version, a dialog box opens, similar to the one shown in Figure 5.1.

Figure 5.1 The main GUI of Comodo Antivirus for Linux

In the main window, you can see the last time that antivirus signatures were updated, as well as a summary of the number of malwares that were detected, and so on. When you click the Antivirus tab, the screen displays an Update Virus Database option, as shown inFigure 5.2.

Figure 5.2 Comodo offers an Update Virus Database option for the Linux GUI

The Update Virus Database option is the first part of the updating protocol that you will dissect. Before clicking this option, you need to launch Wireshark as root in a terminal:

$ sudo wireshark

You then choose Capture→Start from the main menu. To get a cleaner traffic capture log, you can add the HTTP filter. After setting up Wireshark, you click the Update Virus Database option to instruct the GUI to check for new updates of their virus definition files. After a while, you see results similar to those shown in Figure 5.3.

Figure 5.3 Wireshark shows a trace of a signature's updating check [c05f003.eps]

The update tool downloads from http://download.comodo.com/av/updates58/versioninfo.ini.

If you download this text file and check its contents, you see the following:

$ GET http://download.comodo.com/av/updates58/versioninfo.ini

[VersionInfo]

MaxAvailVersion=20805

MaxDiff=150

MaxBase=20663

MaxDiffLimit=150

This is one INI-formatted file with just one section, VersionInfo, and four fields. You still know nothing about the meaning of any of the fields, although you can guess that MaxAvailVersion indicates the latest available version. Now you try to find where that string appears in the Comodo antivirus files:

$ grep 20805 -r /opt/COMODO/

/opt/COMODO/etc/COMODO.xml: <BaseVer>0x00005145 (20805)</BaseVer>

You have a hit! It seems that the COMODO.xml file is where the MaxAvailVersion value exists. This field indicates the latest version of the signature files. If the value in the versioninfo.ini file is higher than the value in COMODO.xml, then updates are downloaded. To continue with this example, you can change the BaseVer value in COMODO.xml to 20804 to force the GUI tool to download the latest updates (for this example, you just wait until there is a new set of signatures). If you click the Update Virus Database option, then Wireshark displays a different trace, as shown in Figure 5.4.

Figure 5.4 Request made to the Comodo web servers to download updates

Okay, you now know how to determine whether new signatures are available and where to download them. If the MaxAvailVersion value is higher in versioninfo.ini than in the COMODO.xml file, then updates become available in a URL like this one:http://cdn.download.comodo.com/av/updates58/sigs /updates/BASE_UPD_END_USER_v<<MaxAvailVersion>>.cav.

If you try to download this file using your favorite web browser, or any tool with support to open remote files, you see a binary file with a header that starts with the magic CAV3:

$ pyew http://cdn.download.comodo.com/av/updates58/sigs/updates/

BASE_UPD_END_USER_v20806.cav

000 43 41 56 33 46 51 00 00 52 9A E9 54 44 92 95 26 CAV3FQ..R..TD..&

010 43 42 01 00 05 00 00 00 01 00 00 00 00 00 00 00 CB..............

020 01 00 00 00 42 00 22 00 00 43 42 02 00 05 00 00 ....B."..CB.....

030 00 01 00 00 00 00 00 00 00 01 00 00 00 42 00 22 .............B."

040 00 00 43 42 03 00 05 00 00 00 01 00 00 00 00 00 ..CB............

050 00 00 01 00 00 00 42 00 22 00 00 43 42 04 00 0A ......B."..CB…

060 00 00 00 06 00 00 00 00 00 00 00 02 00 00 00 E2 ................

070 00 6A 2C CC AC 00 22 00 00 43 42 05 00 05 00 00 .j,…"..CB.....

080 00 01 00 00 00 00 00 00 00 01 00 00 00 42 00 22 .............B."

090 00 00 43 42 06 00 0D 00 00 00 09 00 00 00 00 00 ..CB............

0A0 00 00 01 00 00 00 43 00 00 00 20 00 00 00 00 00 ......C… .....

0B0 22 00 00 43 42 20 01 A8 1F 20 00 A8 1F 20 00 00 "..CB … … ..

0C0 00 00 00 46 05 00 00 00 00 00 00 00 00 00 00 00 …F............

0D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

The contents of this binary file look like the Comodo antivirus signatures. The latest public version available for download is 20806 (as of January 23, 2015). Your next step should be to see if it is the latest available version:

$ HEAD http://cdn.download.comodo.com/av/updates58/sigs/updates/

BASE_UPD_END_USER_v20813.cav

200 OK

Connection: close

Date: Fri, 23 Jan 2015 08:52:48 GMT

(…)

$ HEAD http://cdn.download.comodo.com/av/updates58/sigs/updates/

BASE_UPD_END_USER_v20814.cav

200 OK

Connection: close

Date: Fri, 23 Jan 2015 08:52:52 GMT

(…)

$ HEAD http://cdn.download.comodo.com/av/updates58/sigs/updates/

BASE_UPD_END_USER_v20815.cav

404 Not Found

Connection: close

Date: Fri, 23 Jan 2015 08:52:54 GMT

(…)

It seems that more new BASE_UPD_END_USER files (the latest is 20815) are available in the server, but, for some reason, the latest version they want to be installed is 20806. This may indicate that these new signature files are beta signatures (sets of signatures that are still not very reliable) that they want to be available so that support services can download them for customers who need to remove a specific piece of malware. Or it may simply be that the versioninfo.ini file was not updated at the time you checked. You can't really know, but, at least, you learned the following:

· How the antivirus software checks whether a new version of its virus definition files is available

· The exact remote path to download the update files from

However, you still do not know how the antivirus software is updated, if at all; you just learned how to update the signature files. Returning to the Comodo antivirus GUI, if you click the More tab, you will find the Check for Updates option. Start a new, clean Wireshark trace and click that option to see what happens. After a while, the antivirus tells you that you have the latest version and provides a full trace in Wireshark that you can use to determine how it concluded there are no more versions (see Figure 5.5).

Figure 5.5 The recorded trace checking for new Comodo product files

This trace shows the antivirus downloads in an XML-formatted file: http://cdn.download.comodo.com/cavmgl/download/updates/release/inis_1800/cavmgl_update_x64.xml.

Try to open the file in your favorite web browser to determine what the purpose of this software is (see Figure 5.6).

Figure 5.6 XML file to update Comodo software for Linux

The cavmgl_updates tag includes various file XML tags. Each XML tag contains a set of files that can be updated with the filename, its file size, the SHA1 hash, and the base URI from which to download it (from the src attribute); they also contain information about where to copy it (<copy folder="repair">) and whether the antivirus must be rebooted after updating that file (requireReboot="true"). Pick the file libSCRIPT.so and check its SHA1 hash in your installation directory:

$ sha1sum /opt/COMODO/repair/libSCRIPT.so

bbd369a115adb6551286c7d63687541573592d3d repair/libSCRIPT.so

The SHA1 hash is the same, so this file is not upgradeable. Continue checking all the SHA1 hashes of all the files appearing in the XML file. The SHA1 hash corresponds to the files you just installed. Add one byte to the file libSCRIPT.so:

# cp libSCRIPT.so libSCRIPT.so-orig

# echo A >> libSCRIPT.so

# sha1sum libSCRIPT.so

15fc298d32f3f346dcad45edb20ad20e65031f0e libSCRIPT.so

Now, click Check for Updates again in the Comodo antivirus GUI tool. Hmm…nothing happens. You need to change something else. If you find the file libSCRIPT.so in the installation directory of the antivirus product, you will discover more occurrences:

# find /opt/COMODO/ -name "libSCRIPT.so"

/opt/COMODO/repair/libSCRIPT.so

/opt/COMODO/repair/scanners/libSCRIPT.so

/opt/COMODO/scanners/libSCRIPT.so

You have more files to replace. Chances are good that after copying the files to libSCRIPT.so, the updater then replaces the other files. However, you are not updating this file from the GUI tool; you replaced it manually. Try to replace the other two occurrences with your new file:

# cp /opt/COMODO/repair/libSCRIPT.so /opt/COMODO/repair/scanners/

# cp /opt/COMODO/repair/libSCRIPT.so /opt/COMODO/scanners/

Now, go back to Wireshark, start a new, clean trace, and then go to the antivirus GUI tool and click Check for Updates. Hurrah! This time the antivirus software says there is an available update. If you click the Continue button and let it finish the process, it downloads the libSCRIPT.so file. You can check it in Wireshark, as shown in Figure 5.7.

Figure 5.7 Tracing the download of the libSCRIPT.so component

You have now finished dissecting this trivial example to analyze protocol! What's next? You may want to write an exploit for this update protocol, as you just discovered the following vulnerabilities for it:

· Everything is downloaded via HTTP.

· The integrity of downloaded files is verified with a cryptographic hash, but no signature check is made to determine whether or not a file was created by Comodo developers.

· The catalog file is not signed. In fact, you did not observe signature checks anywhere.

Because of those update protocol weaknesses, if you can launch an MITM attack in a LAN, for example, you can change the contents and install anything you want (as long as you write an exploit that supplies an XML catalog file as expected by the Comodo antivirus software). Oh! By the way, by exploiting this bug, you can install files as the root user anywhere you want. Isn't it cool?

When Protection Is Done Wrong

Some antivirus products advertise that they can inspect HTTPS, the HTTP protocol when encrypted with SSL/TLS. What it really means is that they use the same actions that malware does to inspect network traffic and protect customers because SSL/TLS, by design, cannot be inspected. In April 2015, Hanno Böck posted an interesting analysis of TLS inspection performed by antivirus software in his blog (https://blog.hboeck.de/archives/869-How-Kaspersky-makes-you-vulnerable-to-the-FREAK-attack-and-other-ways-Antivirus-software-lowers-your-HTTPS-security.html).

As stated in that blog post, an antivirus product that wants to perform TLS inspection must launch an MITM attack and install a certificate signed with a trusted certificate authority for the specific domain to be inspected (like *.google.com), or it must create new certificates for each new site that its users visit, signing them with a valid CA. Antivirus products, legal software like Superfish or PrivDog, and malwares solve this problem in Windows by installing a new root certificate. In the case of antivirus software, this strategy is actually doing the opposite of what is intended: it lowers the security level of the computer being protected by simply circumventing TLS.

According to the previously mentioned blog post, various antivirus products, like Kaspersky or Avast, by default, or ESET, on demand, make use of such techniques to check for malware inside all the HTTPS traffic. This causes a lot of problems in the TLS protocol. For example, all software out there using TLS inspection techniques breaks HTTP Public Key Pinning (HPKP). This technology allows a web page to pin public keys of certificates in a browser. On subsequent visits, the browser will only accept certificates with these keys. This very effective protection against malicious or hacked certificate authorities issuing rogue certificates is actually broken by your antivirus software.

As if this were not bad enough, some TLS interception software implementations, like the one used by Kaspersky, make their customers vulnerable to a plethora of known and fixed attacks against TLS, such as CRIME and FREAK, to name just a few. Also, both Avast and Kaspersky accept nonsensical values for the Diffie Hellman key exchanges, with a size of 8bit, for example. Even worse is that they are actually lowering their own products' protection level when downloading updates from their own servers (if they happen to use TLS at all). This is unacceptable from the protection point of view. On the other hand, it makes the life of an exploit writer easier: the antivirus itself is allowing you to launch many other attacks that, without a browser, would not be possible even if the computer has all the operating system updates installed.

Summary

This chapter covered various topics pertaining to update services, such as how they generally work in modern antiviruses, which transport protocols are typically used, and the security shortcomings arising from incorrect and insecure implementations:

· Update files packaging—It is important to be able to update only the changed part and minimize the network traffic used. Catalog files are typically used in update services to describe the files to be updated, their hashes, and other metadata needed during the updating process.

· Transport protocol—Using insecure channels such as HTTP opens the user to MITM attacks, among other things. However, using an encrypted update channel alone is not enough.

· Update package integrity verification—It is possible to use an unencrypted channel but still validate the integrity of the update files. However, the converse is incorrect: a secure update channel, for example, HTTPS, without proper file integrity checks is pretty useless.

· Insecure update service implementations are not a myth—An in-depth look at how a commercial AV update service works proves otherwise. As it turns out, the update service in question uses the unencrypted HTTP protocol and employs a catalog file containing the list of files to be updated along with their hashes. A good protection one would think, but its weakness was that the catalog file itself is not validated, thus it is possible to serve a modified catalog file with a list of files that the attacker controls along with their correct hashes.

This chapter concluded with a discussion about how HTTPS interception methods used by popular antivirus products actually break HTTPS certificate pinning and render the customers' machines more unsafe.

This is the last chapter in the first part of this book, where all the important introductory and background material has been laid out. In the next part of this book, titled “Antivirus Software Evasion,” we start discussing how to evade the various parts of the antivirus software that were discussed during the first part of this book.