Conficker is the name applied to a sequence of malicious software. It initially exploited a flaw in Microsoft software, but has undergone significant evolution since then (versions A through E thus far). This column summarizes some of the most interesting aspects of Conficker from the viewpoint of an insider who has been analyzing it. The lessons for the future are particularly relevant.
In mid-February 2009, something unusual, but not unprecedented, occurred in the malware defense community. Microsoft posted its fifth bounty on the heads of those responsible for one of the latest multimillion-node malware outbreaks.4 Previous bounties have included Sasser (awarded), Mydoom, MSBlaster, and Sobig. Conficker's alarming growth rate in early 2009 along with the apparent mystery surrounding its ultimate purpose had raised enough concern among whitehat security researchers that reports were being distributed to the general public and raising concerns in Washington, D.C.
Was it all hype and of relative small importance among an ever-increasing stream of new and sophisticated malware families? What weaknesses in the ways of the Internet had this botnet brought into focus? Why was it here and when would it end? More broadly, why do some malware outbreaks garner wide attention while other multimillion-victim epidemics (such as Seneka) receive little notice? All are fair questions, and to some degree still remain open.
In several ways, Conficker was not fundamentally novel. The primary infiltration method used by Conficker to infect PCs around the world was known well before Conficker began to spread in late November 2008. The earliest accounts of the Microsoft Windows buffer overflow used by Conficker arose in early September 2008, and a patch to this vulnerability had been distributed nearly a month before Conficker was released. Neither was Conficker the first to introduce dynamic domain generation as a method for selecting the daily Internet rendezvous points used to coordinate its infected population. Prior malware such as Bobax, Kraken, and more recently Torpig and a few other malware families have used dynamic domain generation as well. Conficker's most recent introduction of an encrypted peer-to-peer (P2P) channel to upgrade its ability to rapidly disseminate malware binaries is also preceded by other well-established kin, Storm worm being perhaps the most well-known example.
Nevertheless, among the long history of malware epidemics, very few can claim sustained worldwide infiltration of multiple millions of infected drones. The rapidly evolving set of Conficker variants do represent the state of the art in advanced commercial Internet malware, and provide several valuable insights for those willing to look close.
Nearly from its inception, Conficker demonstrated just how effective a random scanning worm can take advantage of the huge worldwide pool of poorly managed and unpatched Internet-accessible computers. Even on those occasions when patches are diligently produced, widely publicized, and auto-disseminated by operating system (OS) and application manufacturers, Conficker demonstrates that millions of Internet-accessible machines may remain permanently vulnerable. In some cases, even security-conscious environments may elect to forgo automated software patching, choosing to trade off vulnerability exposure for some perceived notion of platform stability.7
Another lesson of Conficker is the ability of malware to manipulate the current facilities through which Internet name space is governed. Dynamic domain generation algorithms (DGAs), along with fast flux (domain name lookups that translate to hundreds or thousands of potential IP addresses), are increasingly adopted by malware perpetrators as a retort to the growing efficiency with which whitehats were able to behead whole botnets by quickly identifying and removing their command and control sites and redirecting all bot client links. While not an original concept, Conficker's DGA produced a new and unique struggle between Conficker's authors and the whitehat community, who fought for control of the daily sets of domains used as Conficker's Internet rendezvous points.2
Yet another lesson from the study of Conficker is the ominous sophistication with which modern malware is able to terminate, disable, reconfigure, or blackhole native OS and third-party security services.6 Today's malware truly poses a comprehensive challenge to our legacy host-based security products, including Microsoft's own anti-malware and host recovery technologies. Conficker offers a nice illustration of the degree to which security vendors are challenged to not just hunt for malicious logic, but to defend their own availability, integrity, and the network connectivity vital to providing them a continual flow of the latest malware threat intelligence. To address this concern, we may eventually need new OS services (perhaps even hardware support) specifically designed to help third-party security applications maintain their foothold within the host.
Perhaps one of the main reasons why Conficker had gained so much early attention was our initial lack of understanding of why it was there. From analyzing its internal binary logic, there is little mystery to Conficker. It is, in fact, a robust and secure distribution utility for disseminating malicious binary applications to millions of computers across the Internet. This utility incorporates a potent arsenal of methods to defend itself from security products, updates, and diagnosis tools. Its authors maintain a rapid development pace and defend their current foothold on their large pool of Internet-connected victim hosts.
Nevertheless, knowing what it can do does not tell us why it is there. What did Conficker's authors plan to send to these infected drones and for what purpose? Early speculation included everything from typical malware business models (spam, rogueAV, host trading, data theft, phishing), to building the next 'Dark Google',5 to fears of full-fledged nation-state information warfare. In some sense, we are fortunate that it now appears that Conficker is currently being used as a platform for conducting wide-scale fraud, spam, and general Internet misuse (rather traditional uses with well-understood motives). As recently as April 2009, Conficker-infected hosts have been observed downloading Waledec from Waledec server sites, which are known to distribute spam. Conficker has also been observed installing rogue antivirus fraudware, which has proven a lucrative business for malware developers.3
Conficker has been somewhat of a catalyst to help unify a large group of professional and academic whitehats.
From October to April 2009, Conficker's authors had produced five major variants, lettered A through E: a development pace that would rival most Silicon Valley startups. With the exception of Conficker's variant E, which appeared in April and committed suicide on May 5th, Conficker is here to stay, barring some significant organized eradication campaign that goes well beyond security patches. Unlike traditional botnets that lay dormant until instructed, Conficker hosts operate with autonomy, independently and permanently scanning for new victims, and constantly seeking out new coordination points (new Internet rendezvous points and peers for its P2P protocol). However, despite their constant hunt for new victims, our Conficker A and B daily census (C is an overlay on prior-infected hosts) appears to have stabilized at between approximately 5 and 5.5 million unique IP addresses (as of July 2009).1 Nevertheless, any new exploit (a new propagation method) that Conficker's authors decide to distribute is but one peer exchange away from every current Conficker victim. It is most probable that Conficker will remain a profitable criminal tool and relevant threat to the Internet for the foreseeable future.
Yes. Perhaps in ways the Conficker developers have not foreseen and certainly to their detriment, Conficker has been somewhat of a catalyst to help unify a large group of professional and academic whitehats. Organized groups of whitehats on invitation-only forums have certainly previously self-organized to discuss and share insights. But Conficker brought together a focused group of individuals on a much larger scale with a clearly defined target, now called the Conficker Working Group (CWG).1
The details of the CWG and its structure are outside the scope of this column, but the output from this group provides some insight into their capabilities. Perhaps its most visible action has been the CWG's efforts to work with top-level domain managers to block Internet rendezvous point domains from use by Conficker's authors. Additionally, group members have posted numerous detailed analyses of the Conficker variants, and have used this information to rapidly develop diagnosis and remediation utilities that are widely available to the general public. They actively track the infected population, and have worked with organizations and governments to help identify and remove infected machines. They continue to provide government policymakers, the Internet governance community, and Internet data providers with information to better reduce the impact of future malware epidemics. Whether such organized efforts can be sustained and applied to new Internet threats has yet to be demonstrated.
1. Conficker Working Group Web site (June 2009); http://www.confickerworkinggroup.org
2. Giles, J. The inside story of the Conficker worm. New Scientist Journal (June 12, 2009); http://www.newscientist.com/article/mg20227121.500-the-inside-story-of-the-conficker-worm.html?full=true
3. Krebs, B. Massive profits fueling rogue antivirus market. The Washington Post (Mar. 16, 2009); http://voices.washingtonpost.com/securityfix/2009/03/obscene_profits_fuel_rogue_ant.html
4. Lemos, R. Cabal forms to fight Conficker, offers bounty. Security Focus (Feb. 13, 2009); http://www.securityfocus.com/news/11546
5. Markoff, J. The Conficker worm: April Fool's joke or unthinkable disaster? Bits: The New York Times (Mar. 19, 2009); http://bits.blogs.nytimes.com/2009/03/19/the-conficker-worm-april-fools-joke-or-unthinkable-disaster/
6. Porras, P.A., Saidi, H., and Yegneswaran, V. Conficker C analysis. SRI International Technical Report (Apr. 4, 2009); http://mtc.sri.com/Conficker/addendumC/#SecurityProductDisablement
7. Williams, C. Conficker seizes city's hospital network. The Register (U.K.) (Jan. 20,2009); http://www.theregister.co.uk/2009/01/20/sheffield_conficker/
The Digital Library is published by the Association for Computing Machinery. Copyright © 2009 ACM, Inc.
No entries found