Denial of Service - Antivirus Software Evasion - The Antivirus Hacker's Handbook (2015)

The Antivirus Hacker's Handbook (2015)

Part II. Antivirus Software Evasion

Chapter 11. Denial of Service

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.

Local Denial-of-Service Attacks

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:

· Compression bombs (also available remotely)

· Bugs in file format parsers (also available remotely)

· Attacks against kernel drivers

· Attacks against network services (available remotely, although some network services may only listen at the localhost IP address, 127.0.0.1)

The following sections cover several of these local DoS bug categories, as well as their implications from an attacker's point of view.

Compression Bombs

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.

Screenshot of the one-day antivirus test results presenting a table of failing antiviruses, such as ESET, BitDefender, Sophos, Comodo, AVG, Ikarus, and Kaspersky, on various compression file formats.

Figure 11.1 Slide from the “Breaking AV Software” talk at SyScan 2014 showing an antivirus program affected by the compression bombs bug

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.

Creating a Simple Compression Bomb

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.

Image described by caption and surrounding text.

Figure 11.2 VirusTotal results showing time outs in two antivirus programs

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/.

Image described by caption.

Figure 11.3 VirusTotal error message trying to analyze a 32GB dummy file compressed with XAR

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).

Bugs in File Format Parsers

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_dir\file-causing-parsing-bug.bin

base_dir\sub-folder\real-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.

Attacks against Kernel Drivers

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:

1. An attacker abuses a vulnerability that allows one of the following: a file to be copied to a user's Startup directory, a bug that allows a driver to be installed, or a bug that allows a library to be copied in a location that will later be picked up and loaded in the address space of high-privileged processes after rebooting.

2. The attacker then uses a kernel driver bug to force the machine to reboot so that the changes take effect.

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.

Screenshot of a Search page of the www.exploit-db.com listing dates, description, platforms, and authors of vulnerabilities.

Figure 11.4 Proofs-of-concepts exploiting DoS bugs

Remote Denial-of-Service Attacks

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:

· Compression bombs, as in the case of local denial of services

· Bugs in file format parsers, as in the case of local denial of services

· Bugs in network protocol parsers

· Attacks against antivirus network services that listen to network interfaces other than the loopback network interface (localhost IP address, 127.0.0.1)

I discuss some of these attack vectors and how they can be used remotely in the following sections.

Compression Bombs

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:

1. An attacker sends an email to a target email box with a compression bomb attached.

2. As soon as the email is received, the antivirus software analyzes the file.

3. Immediately after sending the previous email, the attacker sends another one with a piece of malware.

4. While the antivirus product is still analyzing the previous file (the compression bomb), the unsuspecting user opens the attachment in the second email, which the attacker sent, and becomes infected.

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).

Bugs in File Format Parsers

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:

1. The attacker creates a malicious web page that somehow fingerprints the antivirus software. Alternatively, it may simply target one or more specific antivirus products without first fingerprinting.

2. If a vulnerable antivirus is detected, the attacker server sends a web page with an 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.

3. After a few seconds, or when some event happens, the malicious web page executes a piece of JavaScript exploiting a vulnerability in the browser.

4. Because the antivirus program was disabled via a DoS bug for a file format parser, the exploitation process is not detected, and so the targeted user is infected.

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.

Summary

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:

· Compression bombs—These are also known as a “zip of death.” A simple compression bomb attack involves a file that is highly compressible, that when unpacked may consume hundreds of megabytes of memory if not gigabytes. This naturally would cause the AV to become busy, thus creating a small window of time where the real malware can slip in undetected. This kind of attack can affect almost any kind of antivirus.

· Bugs in file format parsers—These bugs, even when as trivial as a divide-by-zero, a null pointer dereference, or a format parsing bug leading to an infinite loop, can cause the antivirus service or scanner to crash, giving the attacker a chance to carry out a temporary attack during the time the antivirus's watchdog has not yet restarted the crashed services.

· Attacks against kernel drivers—Kernel drivers, such as filesystem filter drivers, network filter drivers, or other kernel components of an antivirus, may contain logic or design bugs that can lead to exploitation. If this is the case, then the attacker is able to execute code from kernel mode with the highest privilege.

· Attacks against network services—All of the previously mentioned attacks could be carried remotely as well. A network service, such as an email gateway, can be exploited if it contains file format parser bugs. Similarly, an email containing a compression bomb can be sent to the targeted recipients, which will be intercepted by the email gateway, leading to a DoS attack and perhaps causing a crash in that service.

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.