A case for AV bypasses/evasions

In essence a bypass is simple to understand - the AV scanning engine, that is the logic and code paths that detect if code is malicious or not, are evaded. This is not to be confused with the manipulation of existing malware in order to be no longer detected - these could be consider an "evasion" but only for that single sample - I do not consider these to be a security problem per se.



Evasions presented here are generic, meaning that they represent a generic method to evade detection .


Table of contents
  1. Advisories
  2. Generic evasions through archives
  3. Generic evasions through indirectly influencing code paths
  4. Common misconceptions about this "bug class"

1. Advisories
Here is a list of advisories disclosed by myself :


1. Evasions through archives

In essence a bypass is simple to understand - the AV scanning engine, that is the logic and code paths that detect if code is malicious or not, are evaded. This leads to the AV engine that cannot decompress , and hence analyse the file within the archive correctly but the end user is able to extract and run the file. This implies that the AV detection logic is effectively evaded. (See Figure 1)

The bug results in denying the engine the possibility to inspect code within the archive. While the impact might be low client-side (as code is inspected upon extraction by the user) the impact for gateways or AV infrastructure where the archive is not extracted is considerable. There is no inspection of the content at all, prior disclosure therefore referred to this class of bugs as Denial of service (you deny the service of the scan engine for that file) however I choose to stick the terms of evasion/bypass, being the primary impact of these types of bugs.

This is not new, this "bug class" is known since 2004/2005 and not every Anti-virus vendor cared enough to close these apparent problems, or add a logic for gateway products to allow them to block bypasses on request.

The impact of this problem varies from engine to engine and from product to product and varies from how the customer uses the product. It can however be summarised this way:
  1. Client side: Low impact for AV products using a real-time (on access) scanner, only few like clamav and f-prot do not have this capability. The reason why the impact is low, is that the engine is only evaded/bypassed on scan time (example:scheduled hard disc scan ) but not on runtime, when the user extracts the payload.

  2. Server side: High impact for AV gateway products (E-mail, WWW etc.), since there is no user that extracts the file, it is impossible for gateway to inspect the code and the engine is completely bypassed. Only recently (after a wake up call and proposed solution by Sergio and myself in the presentation "The Death of AV Defense in depth?") vendors started to built a logic into the products that enable the product to block archives they cannot extract. In this case the impact varies whether said option is enabled or disabled by default.

  3. Server side: High impact for AV software on File servers, Database servers or scanners that scan remotely. Code is rarely actively extracted on these server by an end-user and as such the engine can be bypassed completely.

  4. In cloud security services : High impact In cloud services usually don't scan user extracted data and as such are evaded completely. This is also one major reason why I think AV in the cloud is not going to work out, it fails as per design

  5. Online services (Gmail, Hotmail, Yahooetc): High impact.
    It will be very interesting to see which companies will NOT patch their client side bugs and have these on-line AV services left useless. Example :

Below is a simplified logic of an AV engine detection logic (Image source: F-Secure - Link, ), as I annotated below the logic breaks once the file can't be extracted.



Figure 1. Evasion based on specially crafted archives.

I am aware that there are hundreds of ways to bypass using archives, that however doesn't make it less of a problem. This technique can be used and was actively being used, by malware to stay undetected over a longer period of time. The reason why the window of exposure is expanded is that,depending on the type of evasion a AV kernel update (engine update) is necessary and signature updates do not suffice. Resulting in longer window of exposure - at least for Gateway solutions.


2. Evasions through indirectly influencing code paths

Anti-virus products have been highly optimised (in terms of performance) in the recent years, one easy and logical way of doing such optimisations, is to separate your "analysis logic" in separate routines that trigger only on the respective file types. In other words, not all files are completely analysed and treated equally. For files determined to be PE executables for instance a special subset of routines and heuristics is triggered that catches this type of malware.

The evasion happens if you succeed in manipulating a format in such a way that the scanner thinks it is of another filetype. This leads to another branch of code (and hence logic) to be taken that often results in a complete bypass of the code necessary to detect the original malware. Sometimes a simply magic byte is enough, sometimes more elaborate manipulations must take place. Figure 2 shows the above explanations in graphical shape:



Figure 2. Evasion through indirect influence of code paths

The interesting part in this type of evasion is that sometimes they work scan-time and run-time as opposed the the evasions resulting from manipulating archives.

3. Common misconceptions about this "bug class"
  • Misconception 1 : This has the same effect as adding a password to a ZIP file and as such is not a security problem.

    I disagree here is why :
  1. An Gateway scanner explicitly flags archives that are passworded, an example is an E-mail Gateway scanner that adds "Attachment not scanned" to the subject line or in another location. It therefore indicates that the file was not scanned and as such you know that you have to be extra careful. This is not the case with bypasses, the engine does not indicate it has not scanned the attachment, in most cases the engine has not inspected the content at all or has inspected it in a different way.

    Furthermore passworded archive files are easily filterable by a content policy, allowing or denying them, so you have control over them, this is also not the case with bypasses.

  2. Those that refute the problem with the argument that this has the same effect as adding a password to an archive, are completely missing the point. Malware/Worms that use passworded archives exist, the problem is that they have to indicate the password to extract the file within the mail. The result is highly suspicious email and an highly ineffective way of spreading wormable code. In fact it was so suspecious that most e-mail worm authors have dropped even using it. Further more, several AV vendors have added simple code to parse the mail for "password: xxxx" strings and try to extract the file on the gateway using that password.

    In other words, bypasses are the ideal solution for malware/worms authors to spread their code and have a more effective way of evading gateway scanners, and allow them to stay undedected longer (AV kernel update vs. Signature update) and to get their code deeper within the entreprise.
  • Misconception 2 : The problem of bypasses is only an issue on gateway products
Every environment where the archive is not actively extracted by the end-user is affected. For example, fileservers, databases etc. pp. Over the years I saw the strangest environments that were affected by this type of "bug". My position is that customers deserve better security than this.
  • Misconception 3: This is not a security issue because if the gateway might be bypassed the the client-side AV will catch the malware on extraction of the archive.
This argument makes the dangerous presumption that all scanners actually detect that particular malware (which is NOT necessarily the case, take a look at the virustotal.com stats)
  1. Gateway would have detected the malicious code (by signatures or heuristics) but it is bypassed
  2. Client AV does not detect the sample because it doesn't have any signature
  3. ?? oops

This is, as anybody dealing with enterprise AV solutions knows is quite common, and not an unlikely scenario. If you want some proof, see the stats from virustotal for instance.
  • Misconception 4: Behavioural analysis will catch this ?
No, the content is unreadable to the AV engine as such no inspection whatsoever is possible.

  • Misconception 5:These are not security issues, they are simple bugs.

    If you have read all of the above and still believe this to be true, note that my advisories never contain a risk rating, there is a good reason there is none : I can't assess the risk of an application running in a particular environment at customers. So I leave it to others to rate the risk of a bypass, customers and vulnerability databases.

    Hint: If there is a rating, it means it's a security issue.
  1. NIST rate bypasses from a CVSS score of 5 to 10
  2. XForce rate bypasses
  3. Secunia rates it as low


I have been asked to provide a list of vendors that react and do patch bypass/evasions and acknowledge the (obvious) necessity to :
  • F-Secure
  • Avira
  • Mcafee
  • Securecomputing
  • Ikarus
  • Nod32
  • Bitdefender
  • Trendmicro
  • Panda
  • Computer Associates (CA)
  • Comodo
  • AVG
  • Sophos
  • Avast

0 comments

Post a Comment