Security Tools are supposed to prevent attacks. Can the same tool be a door for hackers? Can your shield become the attacker’s arrow? This three part series discusses how security products itself could turn out to be a threat and measures to be safe.

With rising cases of security incidents, more people are using security software like antivirus, firewalls, anti-spyware etc. They are meant to protect users from common security attacks and vulnerabilities. However, ironically, the rising popularity of such software is luring the attackers to target the security software itself as a means to break into a system. Imagine this situation: you are running a secure system with antivirus and other necessary software running on it. You assume that you are safe from the latest threats. But what if the antivirus itself is vulnerable? It means that when a hacker exploits the vulnerability in your security software, he has complete access to your system!

In early 2004, one of the vulnerabilities in the product of Internet Security Systems (ISS) resulted in a major worm outbreak. The worm known as “witty worm” leveraged the ISS firewalls and reportedly infected thousands of PCs worldwide.

According to the latest Symantec Global Internet Security Threat Report, 205 vulnerabilities in security products were discovered in the year 2007. During the period of July to December 2007, a total of 92 vulnerabilities were discovered of which 16% were high severity threats, 30% were medium and 32% were low. Interestingly, majority of the vulnerabilities actually affected the anti-virus products.

Why vulnerability research getting more focused on security products?

It is interesting to see that the vulnerability researchers and hackers are shifting their focus gradually towards the security vendors. There are several reasons behind such shift:

Operating Systems are gradually getting more secure: The Operating Systems like Windows, which had been the favorite target among hackers and security researchers, have improved their security significantly compared to before. This makes it difficult to find flaws in the Operating Systems and hence the ROI of security research in this area is diminishing.

Security products are easy targets: Security products are yet to face the massive public and press scrutiny like what Microsoft faced at one point of time. Firewalls and Antivirus are commonly present in most systems today which make it interesting for the hackers. Often it is easier to break a security system which is less audited than to break operating systems like Windows which has been facing attacks for years and hence heavily audited.

Security vendors conducting research on competing products: Interestingly, Global Internet Security Threat Report Vol XIII by Symantec points out that it is not uncommon for security vendors to conduct research on competing products. This competition will potentially benefit users in the long run and also enhance the security of the security products themselves.

Evolution of Responsible Vulnerability Disclosure: The industry promotes responsible vulnerability disclosure by which a security researcher can disclose the vulnerabilities to the vendor and help them to fix it before going public. This process has helped in the evolution of an ethical and responsible way to conduct vulnerability research and thus encouraged more number of independent researchers and security companies to contribute in vulnerability discovery.

Vulnerabilities in Antivirus Products

Antivirus products have always been a favorite target of hackers and security researchers. There are several sources where one can find the details of such vulnerabilities. Some of them include OSVDB, ICAT, Secunia etc. Dancho Danchev, an independent security consultant and cyber threats analyst, points out in his ZDNet post that “between 2002 and 2005 there were 50 advisories regarding vulnerabilities affecting antivirus products, but between 2005 and 2007, there’s been an increase of 240% with 170 advisories. Moreover, according to a research paper by Feng Xue, presented at this year’s Blackhat Europe, according to the U.S national vulnerability database, 165 vulnerabilities within antivirus products have been reported during the last 4 years.”

Case Study on how iViZ broke multiple Antivirus

We are presenting a case study of vulnerability research conducted by iViZ which provides the software-as-a-service based “On Demand Penetration Testing” solution for applications, networks and compliance. While conducting vulnerability research to improve upon different existing security techniques the iViZ security research team discovered that in certain scenarios, some antivirus software behaved in a way which is not normal. The research results were first provided to the vendors as per the “Responsible Vulnerability Disclosure”. The vendors were provided adequate time to release the patches before the public disclosure.

The research finally resulted in the discovery of six new vulnerabilities in the antivirus products of AVG, Sohpos, F-Prot, avast!, BitDefender and ClamAV.

How was the research conducted?

Test Preparation
The Antivirus Security Testing was conducted over a Linux based Operating System. The test subjects were all Antivirus Software compiled natively to run over a Linux 2.6 kernel.

Almost all the popular and modern Antivirus Software unpacks the packed executables first before attempting to match possible malicious signature against the given binary executable. There are many public packers available like UPX, FSG, Armadillo, ASProtect etc. for which both the packing and unpacking algorithms are known but implementation of such unpacker is non-trivial and error prone if it is not handled correctly and securely.

The testing methodology involved fuzzing various binary executable header fields with the intension of hitting possible bugs (particularly integer overflow/underflows, buffer overruns, NULL pointer dereference etc.) in the AV executable processing code. The various testing script generated huge number of packed/non-packed ELF/PE binaries with corrupted or malformed executable headers, particularly the Program Header and the Section Headers of the sample ELF binary feed as input to our scripts.

In order to process an ELF binary successfully, various memory allocations need to be done for different sections of the binary. The amount of memory required for storing different sections is given in the Program Header and Section headers and hence are user control data fields which can be manipulated before the binary executable is fed into a given Anti virus or any other program that processes such binary executables. If the program processing such malformed executable does not verify inputs from user correctly and securely before processing, there might be various vulnerabilities like buffer overflow (small allocation, big copy), integer overflows (sign/unsigned comparison or cast) etc. During the research conducted by iViZ, multiple such issues resulting in memory corruption, NULL pointer dereference etc. were found.

Test Execution: Fuzzing
Fuzzing is a software testing technique used to find out when a program crashes by providing random or heuristic based inputs to it. The fuzzing methodology used by iViZ research team was based on collection of good amount of both packed and non-packed sample executables and shared library files which were fed into “Format Aware” tools and scripts for alteration of critical information from the Header of the input sample executable.

Broadly, the fuzzing tool set consisted of the following:

• File Format Identifier
• File Format Parser Library
• Fuzzing Libraries

• Bit Alteration
• Byte Alteration
• Byte Replacement with [0x00, 0x01, 0x80, 0xff, 0xfe] etc.

• Test Execution Tool

The Fuzz Testing methodology can be summarized as follows:

• Collection of large sample executables in both PE and ELF format
• Packing of each executable using multiple packers like ASProtect, UPX, Armadillo etc. which are available publicly.
• Feeding each of the packed as well as non-packed executable to File Fuzzing tools which can identify the File Format and Packer for generating fuzzed executables from the input samples.
• Execution of each AV under testing with appropriate parameters to scan the generated fuzzed binaries under closed monitoring tools for detection of possible runtime exceptions.

Analysis: Bug Hunting
The process of analyzing possible crashes during the Fuzz Testing involves reproducing similar faults in the given application with the given input while being traced by a debugger. In most of the cases the debugger can report the type of the fault, i.e. whether it’s a NULL pointer dereference or whether it’s an access violation by the program by trying to access unmapped memory etc. But in order to find out the actual cause of the problem corresponding to the crafted input and hence truly ascertain the security impact of the bug, considerable amount of effort in terms of debugging and reverse engineering is required.

The process of reverse engineering and debugging is particularly harder in case of closed source commercial AV applications because of the unavailability of source code or even the debugging symbols. However to address this problem iViZ internally developed a tool which can identify calls to libc functions even from a stripped executable and re-create the symbol table in the executable.
The methodology followed for bug analysis can be summarized as follows:

• Crash location using a debugger and backtrace recording.
• Symbol Table reconstruction of the binary using iViZ’s internally developed tools in case the tested AV is closed source commercial one.
• Reverse Engineering and Analysis of the AV executable functions obtained from the crash backtrace.
• Proof of Concept code development for demonstrating the possible security impact of the bug or vulnerability.

Multiple vulnerabilities were found in antivirus products that employs the mentioned techniques. Some of the classes of vulnerabilities found are:

• Integer Overflows
• NULL Pointer Dereference
• Heap Memory Corruption
• Double Free

Results
The test resulted in the discovery of six vulnerabilities in AVG, Sophos, F-prot, BitDefender, avast! and ClamAV.

How hackers can break into your system through antivirus?

Let us assume that a user is running an antivirus in your system. The antivirus checks for malicious code in the files processed in the system.

Step 1: Hacker sends a mail with malicious attachment — The attacker creates a specific file which can crash the remote antivirus and sends it as an attachment to the user.

Step 2: Antivirus scans the malicious mail attachment — Once the malicious email is received, the vulnerable antivirus software tries to scan the malicious executable. In case of a vulnerable antivirus, this may result either in antivirus software crash or execution of arbitrary code.

Step 3: Attacker crashes the Antivirus and/or breaks into the system — Depending on the nature of the vulnerability, the antivirus may either get crashed or due to arbitrary code execution vulnerability the hacker may get access to the remote system. The privilege level would be same as the privilege in which the antivirus is running on. In case the antivirus is crashed, the hacker may now send another email with a malicious attachment to easily circumvent the crashed antivirus and infect the system with its malicious payload.

How to stay safe?

For the security product vendors, it is very critical to adopt secure design and coding principles, conduct regular penetration testing, conduct code review and also educate the customers regarding patching the security tools. It is critical to create security assurance programs and customer education program. They need to make their customers understand that security products is yet another software/hardware and no software/hardware can be free of bugs/vulnerabilities and it is important for them to know how to deal with it.

For enterprises and common users it is very critical to understand that security tools can also have vulnerabilities and hence it is critical to use it judiciously. We need to patch the security tools too, create layered defense, use multiple tools and create adequate failover mechanisms.
The next part of this series will discuss further on vulnerabilities in security products and details of the measures that users and product vendors should take to stay secure.

—By: Bikash Barai. He is the CEO & co-founder of iViZ (www.ivizsecurity.com) — an On-Demand Penetration Testing company which provides security testing for applications, networks and compliance. Additional credits to Abhisek Datta and iViZ Vulnerability Research Team.