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.
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:
The following hypothetical antivirus update protocol shows you how a typical update might work:
This hypothetical protocol resembles how many real-world antivirus update engines work. You will see more concrete examples in the following sections.
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:
Recent antivirus products rely on insecure or unencrypted protocols based on HTTP for various reasons. The following are the most common ones:
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:
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:
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.
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.
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 in Figure 5.2.
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.
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.
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:
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).
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).
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.
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:
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?
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.
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:
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.
18.188.154.252