Both local and remote denial-of-service (DoS) attacks against antivirus software are possible; indeed, one of the most common attacks is aimed at disabling AV protection. This chapter covers some common DoS vulnerabilities and how to discover such bugs.
A DoS is an attack launched against software or against a machine running some software, with the aim of making the targeted software or machine unavailable. Various types of DoS attacks can be carried out against an AV program. For example, a typical DoS attack against AV software attempts to disable the software or remove it from the machine that is being infected or that has already been infected. Such an attack is important to the operation of the malware; the attack ensures the malware's persistence by preventing a future antivirus update from removing or cleaning it.
DoS attacks that aim at disabling AV software are known as “antivirus killers.” They are implemented in malware as independent tools or modules that know how to terminate known antivirus software by capitalizing on weaknesses and vulnerabilities found using techniques discussed in this book. Most so-called DoS attacks that involve antivirus killers are incorrectly labeled as DoS, because they require the attacker to have administrator privileges in the infected machine in order to uninstall the antivirus software or disable the Windows services of the corresponding antivirus solution. In the following sections, I ignore such “attacks” and focus on true attacks: those that can be launched by a local user with low-level privileges or remotely using any of the vectors that are mentioned in previous chapters.
A local denial of service is a DoS attack that can be launched only from the same machine on which the targeted antivirus software is installed. There are many different types of local DoS attacks, with the following ones being the most common:
The following sections cover several of these local DoS bug categories, as well as their implications from an attacker's point of view.
A simple, well-known, and widely available local denial-of-service attack against antivirus software is the compression bomb, also referred to as a zip bomb or the “zip of death.” A compression bomb can be a compressed file with many compressed files inside that, in turn, have many compressed files inside, and so on. It can also be a really big file, in the order of gigabytes, that, when compressed, shrinks down to a very small ratio such as 10MB, 3MB, or 1MB. These bugs can be considered DoS vulnerabilities, although their usefulness is limited. Such bugs are practically immortal and can affect almost any antivirus software for desktops, servers, network inspection, and so on.
Although compression bomb issues may be addressed and fixed for a given compression file format such as ZIP and RAR, other file formats, such as XAR, 7z, GZ, or BZ2, may be overlooked. In 2014, I performed a quick analysis of some antivirus products and checked to see if they were affected by such bugs. Figure 11.1 shows a table with the results of a one-day test.
An antivirus product, network inspection tool, or other tool affected by such a bug can be disrupted for a number of seconds, minutes, or even forever if it enters an infinite loop. Typically, this attack causes a temporary delay that opens the window for a local attacker to do whatever he or she wants. For example, say that an attacker wants to drop a file that is likely to be detected by the antivirus program onto the local disk. The attacker can first drop a compression bomb, forcing the AV engine to scan the compression bomb, thus preventing the AV engine from doing anything else while the file is being scanned. Meanwhile, during the scan, the real malicious executable is dropped, executed, and removed. This all happens during the time the antivirus service is analyzing the first file that caused the compression bomb attack. Naturally, such an attack is an easy way to temporarily disable the antivirus program and buy the attacker some time to perform unrestrained actions.
In this section, you create a simple compression bomb using common standard Unix and Linux tools. First you need to create a big zero-filled file with the command dd
:
dd if=/dev/zero bs=1024M count=1 > file
After creating this “dummy” file, you need to compress it. You can use any compression tool and format, such as GZip or BZip2. The following command creates a 2GB dummy file and then directly compresses it with BZip2, resulting in a 1522-byte-long compressed file:
dd if=/dev/zero bs=2048M count=1 | bzip2 -9 > file.bz2
You can quickly check the resulting size by using the wc
tool:
$ LANG=C dd if=/dev/zero bs=2048M count=1 | bzip2 -9 | wc -c
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB) copied, 15.619 s, 137 MB/s
1522
While this is a really simple compression bomb attack, you can see how effective it is against several antivirus products by accessing this VirusTotal report: https://www.virustotal.com/file/f32010df7522881cfa81aa72d58d7e98d75c3dbb4cfa4fa2545ef675715dbc7c/analysis/1426422322/.
If you check this report, you will see that eight antivirus products correctly identified it as a compression bomb. However, Comodo and McAfee-GW-Edition displayed the watch icon, as shown in Figure 11.2.
The watch icon means that the analysis timed out, so you know that this attack could be performed against that antivirus program. However, the previous example tested with BZip2. This time, try testing with another compressed file format, 7z. You can compress a 2GB dummy file into a 300KB 7z format file with the following commands:
$ LANG=C dd if=/dev/zero bs=2048M count=1 > 2gb_dummy
$ 7z a -t7z -mx9 test.7z 2gb_dummy
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB) copied, 15.619 s, 137 MB/s
$ 7z a -t7z -mx9 test.7z 2gb_dummy
7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=es_ES.UTF-8,Utf16=on,HugeFiles=on,8 CPUs)
Scanning
Creating archive kk.7z
Compressing 2gb_dummy
Everything is Ok
$ du -hc test.7z
300K kk.7z
300K total
Now upload this file to VirusTotal to see which antivirus product, if any, is affected: https://www.virustotal.com/file/8649687fbd3f801ea1e5e07fd4fd2919006bbc47440c75d8d9655e3018039498/analysis/1426423246/.
In this case, only one antivirus product reported it as a possible compression bomb (VBA32). Notice that Kaspersky timed out during the analysis. Cool! You can use 7z to temporarily disable the Kaspersky antivirus program. Try one more time with another file format: XZ. You can compress your dummy file with the XZ file format using 7z as follows:
$ 7z a -txz -mx9 test.xz 2gb_dummy
This time, a different set of antivirus products—Symantec and Zillya—times out, as you can see in the following report from VirusTotal: https://www.virustotal.com/file/ff506a1bcdbafb8e887c6b485242b2db6327e9d267c4e38faf52605260e4868c/analysis/1426433218/.
Also, note that no antivirus software reported it as a compression bomb at all. What if you create a compressed XAR file, a kind of obscure file format, with an 8GB dummy file inside? I tried to upload it to VirusTotal but it failed, every time I tried, at the final analysis steps, as shown in Figure 11.3. I'm curious about why): https://www.virustotal.com/en/file/4cf14b0e0866ab0b6c4d0be3f412d471482eec3282716c0b48d6baff30794886/analysis/1426434540/.
I manually tested this very same archive against some antivirus products, and it worked against Kaspersky, causing it to time out. Also, note that Kaspersky creates temporary files when analyzing compressed archive files. Do you want to create a 32GB temporary file on the target's machine? This should give you an idea of what you can do—although note that the compressed file is bigger than the previous ones (8GB).
Chapter 8 described how bugs in file format parsers are common in antivirus software; we elaborate more about that in this section. Such bugs can be used as a reliable way to disable an antivirus scanner either locally or remotely. Even a trivial null pointer dereference or a divide-by-zero can be useful because, depending on the antivirus product, it can kill the antivirus scanner service, effectively disabling it until the service is restarted. The antivirus service is usually restarted by some kind of watchdog software (if the antivirus has this feature) or when the machine is restarted.
File format parser bugs can also be used locally to prevent an antivirus scanner from detecting malware. A non-trivial example of this is when the malware drops a malformed file that is known to trigger the bug in the antivirus file parser and cause it to die or become stuck (for example, an infinite loop). In that case, the malformed file is used first in the attack to sabotage the antivirus program prior to mounting the real attack, which will go undetected. This is one of the many low-risk bugs that can be used for disabling an antivirus program. Practically speaking, this trick can be easily applied against older versions of ClamAV (versions prior to 0.98.3) to cause an infinite loop when processing icons inside a PE file's resource directory: a number like 0xFFFFFFFF of icons inside the resource directory will make ClamAV loop forever.
Here is another easier example of how to implement a file format bug. Imagine you have two files with the following path structure:
base_dirfile-causing-parsing-bug.bin
base_dirsub-folder
eal-malware.exe
With this structure, the antivirus program scans the base directory, starting with the first file that triggers the parsing bug; the AV scanner may crash or enter an infinite loop, depending on the parsing bug. The AV program will no longer have a chance to enter the subdirectory to scan the real malware, and thus it will remain undetected. Similarly, as another example of this kind of bug, a malware program can prevent the file from being detected by the antivirus scanner by embedding the file, instead of putting it in the same directory, thus abusing a file format bug. (It will embed the file in the resource directory of a PE file, in the overlay, or even directly in some section of a PE, ELF, or MachO file.) This will not interfere with the malware's program execution and will effectively prevent the antivirus scanner from detecting it.
Other typical examples of local DoS attacks against antivirus products are those focused on kernel driver vulnerabilities. Most antivirus products for Windows deploy kernel drivers that can be used to protect the antivirus program from being killed, to prevent a debugger from attaching to their services, to install a filesystem filter driver for real-time file scanning, or to install an NDIS mini-filter to analyze the network traffic. If the kernel driver has any bugs and a local user can communicate with it and trigger the bug, a local attacker can cause a kernel Bug Check (typically called blue screen of death, or BSOD), which effectively shuts down or reboots the machine. Most typical vulnerabilities discovered in kernel drivers are I/O Control Codes (IOCTLs) for which the received arguments are not correctly checked or validated, if at all.
These tricks are a useful way, for example, to reboot the machine after performing some action without asking the user for confirmation or requiring high-level privileges. They can also be used in a multistage exploit. A hypothetical, yet possible, scenario follows:
Local DoS vulnerabilities in antivirus kernel drivers are very prolific; a few vulnerabilities appear each year, affecting a wide range of antivirus products from the most popular to the less known. Some example vulnerabilities with proofs-of-concepts from previous years can be found on the www.exploit-db.com website, as shown in Figure 11.4.
Remote DoS vulnerabilities can also be discovered in antivirus products, as in any other software with a remote surface that is exposed. A remote denial of service is a DoS attack that can be launched remotely, targeting the antivirus software installed in the victim's computer. There are many possible remote DoS attack vectors, with the following being the most common:
I discuss some of these attack vectors and how they can be used remotely in the following sections.
As in the case of a local DoS, you can use compression bombs to temporarily disable antivirus software remotely. Depending on the antivirus software product and email clients, here is how a remote DoS attack can take place:
Naturally, this attack scenario depends on how each antivirus product and email client behaves. Some antivirus products, but not all, block until each email is fully scanned. However, because this gives the user the impression that his or her email is slow, many antivirus products do not block the user. Again, it depends on both the antivirus and email client software, as some email clients will launch synchronous processes to analyze the email attachments for malicious content (blocking the email client for as long as the antivirus scanner takes to analyze the compression bomb).
Many antivirus products come with heuristics for exploit prevention. Such technologies can be implemented in many ways, but they usually focus on office suite and browser software. A bug in an antivirus file format parser can be exploited remotely, using a browser. Here is an example scenario to illustrate this type of attack:
iframe
pointing to a file that causes a crash in the antivirus scanner, effectively disabling it. Alternatively, when fingerprinting techniques are not used, the malicious web page may try to serve all the malformed pages that crash the entire supported list of antiviruses, one by one, until the specific antivirus belonging to the user crashes.This attack is very likely to be used in a real scenario. However, there is no publicly known exploit or malware using it so far.
This chapter covered various DoS vulnerabilities and how to discover them and use them against antivirus. A typical local DoS attack against antivirus software is one that is launched with low privileges, escalates privileges, and then attempts to disable the software or uninstall it from the machine that is being infected or that has already been infected. On the other hand, a typical remote DoS attack against antivirus software is one that is targeting its remotely accessible services—those that can be reached from the outside without first having local access. An example of that is when the attacker sends a malicious email to the target or uses social engineering to persuade the target to visit a malicious website.
The following different kinds of local and remote DoS attacks were described in this chapter:
The next chapter discusses research methodology and static analysis techniques pertaining to antivirus software in order to find bugs, weaknesses, design flaws, and other relevant information that help you understand how the antivirus works and how to evade it.
18.191.168.203