How clean is clean?

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.

Latest articles:

Bulletin Archive