I found a real live instance of the Delphi-attacking virus W32/Induc-A yesterday. It was in the executable for FinalBurner Free from ProtectedSoft (ironic name in the circumstances), a decent freeware CD burning application. The file is burner.exe and I suspect the company has been shipping it for some time. I do not know if it affects the paid-for versions.
This malware was highlighted by Sophos though one thing Sophos does not make clear (as it is in the scaremongering business) is that the virus has only a mild affect. It only affects machines with ancient versions of Delphi installed – versions 5, 6 and 7 according to Marco Cantu – and its activity appears to be limited to replication. In other words, a successfully infected machine modifies Delphi’s runtime library so that it compiles infected executables, but does nothing else that I know of.
The implication is that the anti-virus companies, far from doing a great job at protecting us, have only just spotted a problem that has been around for months or possibly years. The burner.exe I found was dated 16 June 2009. If anyone has an older example, I would be interested to know; I’ve seen one report of an August 2008 infection.
Thus, when Delphi Product Manager Mike Rozlog comments to the Register’s report:
The best ways to combat these types of issues are to establish a deployment protocol that checks for viruses and trojans before shipping any applications
you have to ask: how? Clearly scanning with an anti-virus product would not have helped ProtectedSoft. Note that Sophos admits in its database that protection has been available only since 18 August 2009.
Despite the mild impact of W32/Induc-A (as far as we know so far) it is not something to take lightly. The attack looks like a proof-of-concept, to be followed by similar code with more serious impact, or possibly just an experiment that escaped into the wild. Maybe there are other more serious variants that the vigilant anti-virus folk will find in a month or two’s time.
How then can developers protect their machines? Another Reg reader says:
Instead, people should try to ensure the integrity of their development systems. Don’t connect them to the ‘net and don’t play games on them (duh!). Don’t have any foreign executables on them besides the OS and the compiler, transfer the sources there and compile them there. Run some kind of integrity checker to make sure that your compiler distribution hasn’t been tampered with. That sort of stuff.
Good advice, though not trivial to implement. A suggestion for Embarcardero: how about giving some thought to the problem and coming up with an easy means for developers to check the integrity of their runtime library files?
The disturbing aspect of this story is how malware can end up in shipping software from reputable companies; it could even be signed code. How long before something like this ends up in an executable shipped with an operating system itself, maybe with a timed payload so it lies dormant until well distributed?