Thoughts of mass destruction


Peter Cooper

Sophos, UK
Editor: Helen Martin


Years after Chernobyl was released, the potential for hardware-destroying viruses has yet to be fully exploited.

I entered the world of anti-virus in the heady summer of ’98. At the time, WM97/Class-D was proving to be a source of much amusement on the support desk. High-powered company execs and Joe Users alike were calling the support desk to find out who ‘Class.Poppy’ was, and why he/she/it was calling them a jerk. Perhaps more sinister was W95/CIH-10xx (aka Chernobyl), quietly infecting Windows computers worldwide and setting its BIOS-nuking countdown timer to 26 April 1999. WM97/Class-D was just another macro virus, but Chernobyl represented a new virus-writing era: hardware-trashing viruses.

Except it didn’t. Today, years after Chernobyl was released, the potential for hardware-destroying viruses has yet to be fully exploited, despite the fact that the Chernobyl source code is available freely. There could be a number of reasons for this apparent lack of interest: the kids involved with virus-writing in the CIH era have now all grown up and found jobs, while the individuals of today’s virus-writing community have a raft of prefabricated mass-mailing code available to them and constructing a virus can be a simple matter of bolting the components together. It’s true that motherboard manufacturers have taken steps to minimise the impact of BIOS-trashing viruses, but where there’s a will, there’s a way – right? Perhaps the will has gone. Perhaps the end game for J Anonymous Virus Writer is to daub his electronic scribbles and tags all over the Internet without causing lasting damage. After all, graffiti artists don’t knock down walls, they just tag them.

The prevalence of macro viruses dropped at the end of the ’90s. Microsoft Office attachments in emails were no longer blindly being opened as often as they used to be. Could it be that computer users were finally understanding the risks associated with computing? Could people involved with IT training and security evangelism congratulate themselves on a job well done? Partly. However, a more likely explanation is that virus writers were frustrated by the limitations of the macro virus programming environment. At the same time, email servers were blocking Microsoft Office attachments from unknown senders. Combine the increase in user education, the decrease in interest from the virus-writing community and the non-delivery of viruses, and you have a feasible explanation for the drop in reports and new discoveries.

Chernobyl was a memory-resident, file-infecting virus. It could infect many hundreds of Windows files in a short space of time when the user browsed My Computer. A popular entry route for the virus was via illegally copied software and/or software cracks that the user had downloaded. But few modern viruses rely on this method to spread. Worms require a host and a network; these two things normally allow them to propel themselves from place to place. They may include file-infecting routines to spice things up, but mass destruction is not normally on the agenda. Maybe the virus writer of today has a conscience. Or maybe they’re more selfish – programming software that allows them to use other people’s computers for personal or monetary gain is an effective use of their time, and botnet size counts for more than a varied and successful virus-writing portfolio.

And in the future we’ll see more of the same. Inevitably, some new technologies will be targeted and some as yet unused methods of distribution will be exploited. Some will be revisited from days gone by. As voice over IP gathers pace, a firewall-busting distribution network with a convenient vendor-supplied API could be harnessed for mass carnage. Maybe things will go the way of W32/Hybris and utilise newsgroups on Usenet to provide updates and plugins.

Perhaps the next big virus will be a file-infecting, massively distributed worm which auto-updates from Usenet and calls the user a jerk before trashing their BIOS. We’ll see.



Latest articles:

VB99 paper: Giving the EICAR test file some teeth

There are situations that warrant the use of live viruses. There are also situations where the use of live viruses is unwarranted. Specifically, live viruses should not be used when safer and equally effective methods can be used to obtain the…

Powering the distribution of Tesla stealer with PowerShell and VBA macros

Since their return more than four years ago, Office macros have been one of the most common ways to spread malware. In this paper, Aditya K Sood and Rohit Bansal analyse a campaign in which VBA macros are used to execute PowerShell code, which in…

VB2017 paper: Android reverse engineering tools: not the usual suspects

In the Android security field, all reverse engineers will probably have used some of the most well-known analysis tools such as apktool, smali, baksmali, dex2jar, etc. These tools are indeed must‑haves for Android application analysis. However, there…

VB2017 paper: Exploring the virtual worlds of advergaming

As adverts in gaming (‘advergaming’) ecosystems continue to become more sophisticated, so the potential complications grow for parents, children and gamers, who just want to play without having to worry about where their data is going (and how it is…

Distinguishing between malicious app collusion and benign app collaboration: a machine-learning approach

Two or more mobile apps, viewed independently, may not appear to be malicious - but in combination, they could become harmful by exchanging information with one another and by performing malicious activities together. In this paper we look at how…

Bulletin Archive