This week marked 1,000 days since the first appearance of Conficker, a worm that went on to terrorise businesses for most of 2009. Aryeh Goretsky, distinguished researcher at ESET, looks back at the first thousand days and how businesses are keeping up the fight.
It has been 1,000 days since the Conficker worm first appeared on 21st November 2008. For the first two months after its initial appearance, we received a trickle of reports through our ThreatSense.NETtelemetry system. By January of 2009 that had become a flood, then a deluge, as this ‘super worm' rose to meteoric infection levels.
Since then, Conficker has consistently shown up as one of the top ten infections in our monthly Global Threat Reports, usually in the number one or two slot.
We have blogged at length about Conficker, provided free tools to remove it, written whitepapers and even presented on it, as have our colleagues in the anti-malware industry.
Microsoft has released guidance explaining how to patch and protect computers and the Conficker Working Group toils on in semi-obscurity, providing ISPs with a blocklist of 50,000 pseudo-random domain names that some variants of Conficker use to look for updates in order to pre-empt the worm's update mechanism.
The worm received massive amounts of attention in the news as April 2009 approached, when a change to the worm's update mechanism began. This change ultimately seemed to have little effect on the worm.
As for the Conficker worm itself, it appears to have been abandoned by the criminal gang operating it later in 2009. In June of this year, the FBI and US Department of Justice announced arrests of individuals who may have been its authors.
So why is it that nearly three years later, the Conficker worm is running ‘headless' without command and control (C&C), using a three-year-old exploit, yet is still top of the malware ecosystem? The answer to that question is complicated, because it lies not in the cyber realm of ones and zeroes, but far above it in circles where questions of doing what's right and proper give way to concerns of budgets, policies and convenience.
To illustrate this, I would like to share a story with you about a friend of mine we'll call John (not his real name). John works as an administrator at a regional company, where he supports thousands of desktops across several states. I say support and not manage or administer, because of the nature of John's environment: John's employer is a business that has grown by acquiring smaller companies.
As a result the company has dozens, if not hundreds, of different networks, computers, operating environments, best practices and standards for managing all of these. In other words, this is an enterprise-sized deployment of workgroups.
While it has made some inroads towards establishing universal standards, the organisation's computer security is still a patchwork at best. For example, there is no centralised management of security. Coupled with the fact that some users still have administrative access to their PCs due to legacy software, that means that employees can turn off or even uninstall their anti-virus software at will.
What does this mean for John? It means that his company's users have been infected with Conficker somewhere in the company every single day since the worm came out. While there are technical issues that facilitate this pandemic, the underlying cause is not really technical: John's employer has not implemented the means to protect its employees because of the expense of installing a centralised management and security solution.
Such an implementation also has to factor in the cost and inconvenience of replacing legacy programs and computers and training employees on the replacement systems, in the current economic climate.
I agree that solving this particular problem will be very costly. Even using open source software, the company is looking at a significant capital expenditure for deployment and those costs are only going to increase with each acquisition.
Of course, the sooner his company switches to a centralised management and security model, the better off it will be, especially when it comes to integrating acquisitions.
While one might have sympathy for John's employer and understand its desire to fight these hotspots rather than put out the forest fire due to the hit in profitability it will take, there's one other aspect of John's employer I have not mentioned.
It is in the healthcare business.
In the United States, that means it is subject to HIPAA rules. While HIPAA is not something we discuss very often because it is a complicated and specialised area, a worm traversing networks containing medical records for nearly three years seems like it would be the type of thing HIPAA was meant to address.
So what will it take to finally kill Conficker? That's a difficult question to answer. Clearly, anti-malware software and other technical solutions and prescriptive guidance are not enough, nor is the prospect of being fined for violating industry-specific regulations.
Some of the most successful actions against botnets have been taken by US authorities acting in conjunction with Microsoft, to shut down such botnets such as Waledac, Coreflood and most recently, Rustock. These botnets relied on accessing specific domains or computers for their C&C servers and began to vanish as soon as these were seized by the authorities.
While the earliest version of Conficker accessed a single domain, later versions switched to access hundreds and then tens of thousands of random domains on a daily basis, making the worm highly resistant to this type of infrastructural attack.
Providing patches, prescriptive guidance and software to combat the worm are the tools that security and operating system vendors provide to ameliorate threats. Just because they are available however, does not mean they are going to be used or managed correctly, as in the example of John's company.
So where does that leave us? If we cannot do anything now to secure some of our systems, it seems like we will have to rely on future mitigations. When Microsoft released Windows 7, it made a seemingly small change to the way in which the system handles the behaviour of AutoRun, its technology for starting programs from removable media.
This effectively immunised that operating system against worms that spread via AUTORUN.INF files. Microsoft eventually made this available as an update to Windows Vista and Windows XP, although installation isn't mandatory. Windows 7 and Windows Server 2008 R2 were released after the vulnerabilities exploited by Conficker were fixed, which hampers its spread in those environments.
Microsoft has not shared much information with the public about the next version of Windows, but hopefully in Windows 8 we will see additional anti-Conficker refinements in it. Variants of Conficker attempt to spread over network shares, guessing the password based on some commonly used methods and words.
Hard-coding the list into Windows 8 might be overkill for a threat as old as Conficker, but if Windows users are unable or unwilling to manage their security correctly, then enforcing more secure choices, as Microsoft has done with its changes to AutoRun behaviour, may be the only solution. Even if that solution can only spread at the same rate as the new operating system that contains it.
This article originally appeared on the ESET blog http://www.eset.com/about/blog/blog/