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?
Don’t connect development machines to the net! Ouch, that’s gonna hurt.
@Craig I know developers who do this, for security against would-be code stealers as well as for virus protection.
Tim
One of our business applications was infected. The .exe was built in May this year. It would seem that one of the development systems was compromised so only .exes built on that machine were shipped with the malicious code in. No one here develops in Delphi so we haven’t suffered any damage, only the inability to use the app after Sophos started picking it up.
As for not connecting development machines to the net – what if you want updates to e.g. subversion, anti-virus, etc? I guess you could have them only on an internal network, but…
So how much hassle is doing software updates if the machine is not connected to the net?
Also, how would that work anyway? If the code is being developed on a machine that IS on the net (by that I mean any network as even a private LAN increases the risk considerably as any one machine on that LAN may be infected with something), there is always chance of infection from whatever media you are using between that box and the compiler box.
The fact you are switching files between a net connected box and an isolated box just means your isolated box is open to anything the net box is subjected to, with the added catch it wont have virus protection or the latest OS updates. Surely that negates the benefit of it being isolated to begin with?
Sure you can probably request all these updates on disk but you are still trusting the source of those disks do not have any infection themselves.
So at the end of the day, is there as much benefit of having an isolated machine as first thought?
@Alex @Martin all valid issues. In the case I know, there is an isolated 2nd internal network for development – though there must be some manual traffic between that and Internet connected machines. I am not arguing for it, but I can see that is helps reduce some risks.
Tim
One solution is to deploy only executables that are built on a “clean” build system. It may be easier to keep such a system clean than the actual developer system.
I think you are so mild with SOPHOS, its more than “scaremongering”. SOPHOS report lacks of knowledge, literally. Richard Cohen and Graham Cluley are inventing an issue for the users where there is none. The versions of that “Induc” crap only affects old Delphi versions, not the users machines at all. Its almost defamatory for the Delphi brandname (read the articles). Its a shame, and there is no email to complain to them. Thats coward.
Anyway may be it ends up like free adverstising for Embarcadero heh, but i dont know how good it is…
@Javier well, the problem is a real one even though it won’t affect most users. It’s surprising in a way that Sophos has given so much publicity to its own failure – this malware was around for ages undetected by its software.
Tim
“The versions of that “Induc” crap only affects old Delphi versions, not the users machines at all.”
One of our biggest banks here (in Australia) are still on Delphi 6. They are (slowly) replacing their Delphi apps with Java. But with 4000+ workstations to look after, it takes them a long time to do anything.
yes i found an older project on my VM date 19.02.09.
Well, we caught the virus after testing the trial version of SautinSoft RTF-to-HTML (www.sautinsoft.com). The date stamp of their demo program was April 1, 2009. It then infected an update of a retail product we released in mid-July.
Of course, our system is well protected and we had scanned our product through an array of anti-virus products before releasing it (www.virustotal.com). At that time, it was a perfectly safe executable. Now we’re flooded with mail from concerned customers getting virus warnings on our reputable software. Although the virus may be harmless, it certainly manages to damage reputation.
Would we have been safer using an offline computer for our development? No, because we rely on third-party components and testing the SautinSoft RTF-to-HTML product on our offline computer would have infected it just the same.
Eric,
Thanks for noticing about this virus, we’ve fixed the problem. Use this link to download the fixed version of the RTF-to-HTML DLL component.
SautinSoft team
The most *funny* thingt is that this kind of *comilator virus* canaffect any development IDE, not only Delphi.
For me most interesting is the target od IDe 4-7 exactly 4.0 to 7.0. Means that *virus* was targeted to black reputate people that use Inprise, Borland IDE without updates.
Anyway now it requires to thinking about security, when using third-party components.