Nearly three years old, the Conficker worm continues to pose a threat to PCs. Aryeh Goretsky wants to know why this is, and what can be done about it.
It has been 1,000 days since the Conficker worm first appeared on November 21, 2008. For the first two months after its initial appearance we received a trickle of reports through our ThreatSense.NET telemetry system. By January of 2009 that had become a flood, and 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 number two slot.
We have blogged at length about Conficker, provided free tools to remove it, written white papers 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 preempt 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, though.
As for the Conficker worm itself, it appears to have been abandoned by the criminal gang operating it later in 2009, and 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, running “headless” without Command and Control (C&C), using a three year old exploit and dealt with by all current anti-malware software is still the 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, well, workgroups. While they have made some inroads towards establishing universal standards, the organization’s computer security is still a patchwork at best. For example, there is no centralized management of security. That, coupled with the fact that some users still have administrative access to their PCs due to legacy software, means that employees can turn off or even uninstall their antivirus software at will.
And what does this mean for John? It means that his company’s users have been infected with Conficker somewhere in their 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 their employees because of the expense of installing a centralized management and security solution: such an implementation also has to factor 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, they are looking at a significant capital expenditure for deployment, and those costs are only going increase with each acquisition. Of course, the sooner his company switches to a centralized management and security model, the better off they will be, especially when it comes to integrating acquisitions.
While one might have sympathy for John’s employer and understand their desire to fight these hot spots rather than put out the forest fire due to the hit in profitability they’ll 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 they are subject to HIPAA rules. While HIPAA is not something we discuss very often because it is complicated and specialized 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 Command and Control 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. But just because they are available, 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? Well, 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 behavior of AutoRun, its technology for starting programs from removable media. This effectively immunized that operating system against worms which spread via AUTORUN.INF files. Readers of this blog will no doubt recognize this class of malware as having appeared consistently in the Top 10 threats for years, and using a technique also used by Conficker to spread itself. 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 its flagship operating system, Windows 8, but hopefully 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 behavior – may be the only solution. Even if that solution can only spread at the same rate as the new operating system that contains it.
Aryeh Goretsky, MVP, ZCSE