How clean is clean?

2009-09-01

Roel Schouwenberg

Kaspersky Lab
Editor: Helen Martin

Abstract

'If ever there was an argument to be made against a whitelisting-only approach to security, this is it.' Roel Schouwenberg, Kaspersky Lab.


During the middle of August the world suddenly became aware of a new file infector that had been found in the wild: Win32/Induc.A is a virus that targets certain versions of the Borland Delphi compiler. It manages to compile an infected version of SysConst.dcu, an essential Delphi system library.

This means that any Delphi program that depends on this library for compilation will contain the self-replicating code. What it comes down to is that virtually every program compiled will carry the virus.

The idea behind compiler malware is not new. Almost exactly 25 years ago Ken Thompson described a similar and slightly more complex situation than we see with Win32/Induc.A.

Putting this idea into practice also isn’t very new. At the end of 1997, the Russian malware writer ‘Z0mbie’ released two innovative file infectors. One virus targeted TPU files – libraries used by Borland’s famous Turbo Pascal compiler. The other targeted BGI files, which stands for Borland Graphic Interface, a primitive form of video driver.

However, what is more interesting is the fact that Win32/Induc.A has been in the wild for quite a while. Initially it was rumoured to have been in the wild since 2005. Such claims have not been substantiated, but confirmed cases date back to almost 12 months ago. In reality this most likely means that it has been in the wild for more than a year.

How can the AV industry collectively miss a virus for such a length of time? Unless the file is put through an obfuscator or protector after compilation the viral code is highly visible.

The reason most likely has to do with the huge amounts of incoming (malicious) files. It’s rather unlikely that automated processing of these infected files will reveal very much, as the virus needs Borland Delphi installed in order to start its malicious payload.

Even five years ago it would have been unlikely for Win32/Induc.A to have gone unnoticed for such a long period of time. It seems clear that we’ve reached an era where rare dependencies, such as having a compiler on the system, or logic bombs can thrive.

According to some reports Win32/Induc.A is only a proof of concept as it does nothing more than replicate. Clearly, I must have missed the announcement declaring file infection a non-malicious deed. Or perhaps this was it. In this regard it looks like we’re becoming too focused on behaviour such as password stealing. In fact, if Win32/Induc.A hadn’t been causing problems in some cases it would have taken even longer for us to become aware of its existence.

We have seen many thousands of supposedly clean files that turned out to be infected. I’m certain that the clean collection of every AV vendor out there has contained at least some infected files at some point in time. If there was ever an argument to be made against a whitelisting-only approach to security, this is it. Just as there is no 100% detection of malicious code, there is also no 100% guarantee that supposed clean files really are clean.

Malware authors may have done their own analysis of the success of Win32/Induc.A, and I’m inclined to think that from now on we should trust our clean files even less. Not surprisingly, next to all those thousands of apparently clean files there are also many malicious files infected with this virus.

What is more surprising is that Win32/Induc.A-infected trojans were being seeded even several days after the majority of AV vendors had released detection for it. This tells us that these malware authors are not running any AV solution, which is not very surprising. More surprising is that they are apparently releasing new variants without checking them against (up-to-date) AV solutions.

Most likely this means that malware authors have grown so confident in the fact that making minute changes to the source will be enough to evade detection that they are not even bothering to scan the newly created malware any more. Perhaps that is the most worrisome conclusion we can draw from the Win32/Induc.A situation.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.