 |
| Old School Member |
 |
Joined: Thu Sep 14, 2006 4:38 pm
Posts: 473
|
http://mtc.sri.com/Conficker/addendumC/Introduction
This addendum provides an evolving snapshot of our understanding of the latest Conficker variant, referred to as Conficker C. The variant was brought to the attention of the Conficker Working Group when one member reported that a compromised Conficker B honeypot was updated with a new dynamically linked library (DLL). Although a network trace for this infection is not available, we suspect that this DLL may have propagated via Conficker's Internet rendezvous point mechanism (Global Network Impact). The infection was found on the morning of Friday, 6 March 2009 (PST), and it was later reported that other working group members had received other DLL reinfections throughout the same day. Since that point, multiple members have reported upgrades of previously infected machines to this latest variant via HTTP-based Internet rendezvous points. We believe this latest outbreak of Conficker variant C began first spreading at roughly 6 p.m. PST, 4 March 2009 (5 March UTC).
In this addendum report, we summarize the inner workings and practical implications of this latest malicious software application produced by the Conficker developers. In addition to the dual layers of packing and encryption used to protect A and B from reverse engineering, this latest variant also cloaks its newest code segments, along with its latest functionality, under a significant layer of code obfuscation to further hinder binary analysis. Nevertheless, with a careful mixture of static and dynamic analysis, we attempt here to summarize the internal logic of Conficker C.
Implications of Variant C
Variant C represents the third major revision of the Conficker malware family, which first appeared on the Internet on 20 November 2008. C distinguishes itself as a significant revision to Conficker B. In fact, we estimate that C leaves as little as 15% of the original B code base untouched, as illustrated in Appendix 3, A Comparative Assessment of Conficker B and C Process Images. Whereas the recently reported B++ variant represented a more surgical derivative of B, C incorporates a major restructuring of B's previous thread architecture and program logic, including major functional additions such as a new peer-to-peer (P2P) coordination channel, and a revision of the domain generation algorithm (DGA). It is clear that the Conficker authors are well informed and are tracking efforts to eliminate the previous Conficker epidemics at the host and Internet governance level. In Conficker C, they have now responded with many of their own countermeasures to thwart these latest defenses.
For example, C's latest revision of Conficker's now well-known Internet rendezvous logic may represent a direct retort to the action of the Conficker Cabal, which recently blocked all domain registrations associated with the A and B strains. C now selects its rendezvous points from a pool of over 50,000 randomly generated domain name candidates each day. C further increases Conficker's top-level domain (TLD) spread from five TLDs in Conficker A, to eight TLDs in B, to 110 TLDs that must now be involved in coordination efforts to track and block C's potential DNS queries. With this latest escalation in domain space manipulation, C not only represents a significant challenge to those hoping to track its census, but highlights some weaknesses in the long-term viability of how Internet address and name space governance is conducted.
One interesting and minimally explored aspect of Conficker is its early and sophisticated adoption of binary encryption, digital signatures, and advanced hash algorithms to prevent third-party hijacking of the infected population. At its core, the main purpose of Conficker is to provide the authors with a secure binary updating service that effectively allows them instant control of millions of PCs worldwide. Through the use of these binary encryption methods, Conficker's authors have taken care to ensure that other groups cannot upload arbitrary binaries to their infected drone population, and these protections cover all Conficker updating services: Internet rendezvous point downloads, buffer overflow re-exploitation, and the latest P2P control protocol.
In evaluating this mechanism, we find that the Conficker authors have devised a sophisticated encryption protocol that is generally robust to direct attack. All three crypto-systems employed by Conficker's authors (RC4, RSA, and MD-6) also have one underlying commonality. They were all produced by Dr. Ron Rivest of MIT. Furthermore, the use of MD-6 is a particularly unusual algorithm selection, as it represents the latest encryption hash algorithm produced to date. The discovery of MD-6 in Conficker B is indeed highly unusual given Conficker's own development time line. We date the creation of Conficker A to have occurred in October 2008, roughly the same time frame that MD-6 had been publicly released by Dr. Rivest (see http://groups.csail.mit.edu/cis/md6). While A employed SHA-1, we can now confirm that MD-6 had been integrated into Conficker B by late December 2008 (i.e., the authors chose to incorporate a hash algorithm that had literally been made publicly available only a few weeks earlier).
Unfortunately for the Conficker authors, by mid-January, Dr. Rivest’s group submitted a revised version of the MD-6 algorithm, as a buffer overflow had been discovered in its implementation. This revision was inserted quietly, followed later by a more visible public announcement of the buffer overflow on 19 February 2009, with the release of the Fortify report (http://blog.fortify.com/repo/Fortify-SHA-3-Report.pdf). We confirmed that this buffer overflow was present in the Conficker B implementations. However, we also confirmed that this buffer overflow was not exploitable as a means to take control of Conficker hosts. Nevertheless, the Conficker developers were obviously aware of these developments, as they have now repaired their MD-6 implementation in Conficker C, using the identical fix made by Dr. Rivest's group. Clearly the authors are aware of, and adept at understanding and incorporating, the latest cryptographic advances, and are actively monitoring the latest developments in this community.
One major implication from the Conficker B and C variants, as well as other now recently emerging malware families, is the sophistication with which they are able to terminate, disable, reconfigure, or blackhole native operating system (OS) and third-party security services. We provide an in-depth analysis of Conficker's Security Product Disablement logic, to help illustrate the comprehensive challenge that modern malware poses to security products, and to Microsoft's anti-malware efforts. Conficker offers a nice illustration of the degree to which security vendors are being actively 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.
Perhaps the most obvious frightening aspect of Conficker C is its clear potential to do harm. Among the long history of malware epidemics, very few can claim sustained worldwide infiltration of multiple millions of infected drones. Perhaps in the best case, Conficker may be used as a sustained and profitable platform for massive Internet fraud and theft. In the worst case, Conficker could be turned into a powerful offensive weapon for performing concerted information warfare attacks that could disrupt not just countries, but the Internet itself.
Finally, we must also acknowledge the multiple skill sets that are revealed within the evolving design and implementation of Conficker. Those responsible for this outbreak have demonstrated Internet-wide programming skills, advanced cryptographic skills, custom dual-layer code packing and code obfuscation skills, and in-depth knowledge of Windows internals and security products. They are among the first to introduce the Internet rendezvous point scheme, and have now integrated a sophisticated P2P protocol that does not require an embedded peer list. They have continually seeded the Internet with new MD5 variants, and have adapted their code base to address the latest attempts to thwart Conficker. They have infiltrated government sites, military networks, home PCs, critical infrastructure, small networks, and universities, around the world. Perhaps an even greater threat than what they have done so far, is what they have learned and what they will build next.
Conficker C Overview 
Figure 1 illustrates the Conficker C program structure and logic. When initialized, the DLL performs its setup logic, similar to that of A and B, with extensions. At initialization, it checks for the presence of three mutex values on the target host to avoid reinfection. If absent, these three mutexes are created: 1) the mutex name "Global\<string>-7"; 2) the mutex name "Global\<string>-99; and 3) a mutex named pseudo-randomly generated based on the process ID. The <string> in the first two mutex is unique per computer name; it is calculated based on the crc32 hash of the computer name and XOR'ed with a constant. C then installs several in-memory patches to DLLs, and embeds other mechanisms to thwart security applications that would otherwise detect its presence.
C modifies the host domain name service (DNS) APIs to block various security-related network connections (Domain Lookup Prevention), and installs a pseudo-patch to repair the 445/TCP vulnerability, while maintaining a backdoor for reinfection (Local Host Patch Logic). This pseudo patch protects the host from buffer overflows by sources other than those performed by the Conficker authors or their infected peers.
Like Conficker B, C incorporates logic to defend itself from security products that would otherwise attempt to detect and remove it. C spawns a security product disablement thread. This thread disables critical host security services, such as Windows defender, as well as Windows services that deliver security patches and software updates. These changes effectively prevent the victim host from receiving automated software updates. The thread disables security update notifications and deactivates safeboot mode as a future reboot option. This first thread then spawns a new security process termination thread, which continually monitors for and kills processes whose names match a blacklisted set of 23 security products, hot fixes, and security diagnosis tools.
Figure 1: Overview of Conficker C
Conficker C installs itself into the user file system and configures the registry appropriately to invoke its DLL at host startup. It also inserts a variety of extraneous registry keys that are subsequently unused, presumably to cloak its presence (Obfuscating C's Installation and Its Presence). It copies itself into a randomly named DLL located in either the System32 directory, program files directory, or the user's temporary files folder. It deletes all restore points prior to its infection to thwart rollback. C then performs a simple validation of its DLL size, and suicides if this check fails. It sets the DLL's date to the same date as the local kernel32.dll, and sets NT File System (NTFS) file permissions on its stored file image to prevent write and delete privileges. Once installed, the DLL spawns a remote thread, which it attaches to the netsvcs.exe or svchost.exe process, depending on the OS version.
The core elements of Conficker C are incorporated into two threads: a P2P communication thread, and the domain generation and Internet rendezvous point thread. The first thread is embodied in a code segment that has undergone an additional layer of code obfuscation, suggesting a desire by the Conficker authors to hinder its analysis, and thereby providing an obvious point for in depth inspection. We describe the P2P protocol in Peer to Peer Logic. The P2P protocol includes an ability to coordinate with peers over TCP and UDP channels, as well as download and run digitally signed Win32 binaries. Incorporated with the P2P thread is anti-tracing logic that will kill the Conficker C process when run under a debugger. This logic was removed for this analysis. Conficker C also incorporates an HTTP date check function, which is discussed within Peer to Peer Logic.
Finally, C introduces a substantial modification of the DGA and query procedure, discussed in Domain Generation Algorithm. The DGA will be activated on 1 April 2009, and before April 1st it will enter a loop that sleeps 24 hours and then rechecks the date via getlocaltime. Prior to entering the April 1st date check, C will sleep for an initial random interval between 30 and 90 minutes. More specifically, this sleep interval is between 30 and 90 minutes if the local hour is after 11 a.m. and before 7 a.m. If the local time is after 8 a.m. and before 11 a.m., the sleep period will be between 2.5 and 3.5 hours. It will then check for Internet connectivity, and if connected will enter the domain generation logic. The next section describes this logic in greater detail.
Domain Generation Algorithm
The domain generation algorithm and query procedure (Figure 2) have been significantly modified from previous versions of Conficker. Among the potential motivations for these changes may be to address the recent actions of the Conficker Cabal, as it has moved to block future registrations of Conficker A and B domains. Among the key changes, Conficker C increases the number of daily domain names generated, from 250 to 50,000 potential Internet rendezvous points. Of these 50,000 domains, only 500 are queried, and unlike previous versions, they are queried only once per day.
Furthermore, C provides significantly more filtering of the IP addresses produced by the DNS queries. The IP address is rejected if
1. it was associated with a query that returned more than one IP address
2. it is 127.0.0.1 (localhost) or other trivial address
3. it matches an address with an internal blacklist (see Appendix 2 for the full blacklist)
4. another DNS query had previously returned the identical IP. Note, if an organization chooses to register and resolve multiple Conficker C domains to a single IP address, C-infected machines will not contact that IP more than one time
If none of the domains are alive and ready to serve a digitally signed payload, C will sleep for 24 hours, and then will generate a new list of 50,000 domains. The algorithm produces a domain name set that is independent of Conficker A and B, and will overlap these other domain sets only in a rare coincidence. The name of each generated domain is 4 to 10 characters, to which a randomly selected TLD is appended from the following list of 116 suffix (mapping to 110 TLDs):
[ "ac" , "ae" , "ag" , "am" , "as" , "at" , "be" , "bo" , "bz" , "ca" , "cd" , "ch" , "cl" , "cn" , "co.cr" , "co.id" , "co.il" , "co.ke" , "co.kr" , "co.nz" , "co.ug" , "co.uk" , "co.vi" , "co.za" , "com.ag" , "com.ai" , "com.ar" , "com.bo" , "com.br" , "com.bs" , "com.co" , "com.do" , "com.fj" , "com.gh" , "com.gl" , "com.gt" , "com.hn" , "com.jm" , "com.ki" , "com.lc" , "com.mt" , "com.mx" , "com.ng" , "com.ni" , "com.pa" , "com.pe" , "com.pr" , "com.pt" , "com.py" , "com.sv" , "com.tr" , "com.tt" , "com.tw" , "com.ua" , "com.uy" , "com.ve" , "cx" , "cz" , "dj" , "dk" , "dm" , "ec" , "es" , "fm" , "fr" , "gd" , "gr" , "gs" , "gy" , "hk" , "hn" , "ht" , "hu" , "ie" , "im" , "in" , "ir" , "is" , "kn" , "kz" , "la" , "lc" , "li" , "lu" , "lv" , "ly" , "md" , "me" , "mn" , "ms" , "mu" , "mw" , "my" , "nf" , "nl" , "no" , "pe" , "pk" , "pl" , "ps" , "ro" , "ru" , "sc" , "sg" , "sh" , "sk" , "su" , "tc" , "tj" , "tl" , "tn" , "to" , "tw" , "us" , "vc" , "vn" ]Code: XP
http://download.microsoft.com/download/4/f/a/4fabe08e-5358-418b-81dd-d5038730b324/WindowsXP-KB958644-x86-ENU.exe
Vista
http://download.microsoft.com/download/d/c/0/dc047ab9-53f8-481c-8c46-528b7f493fc1/Windows6.0-KB958644-x86.msu
_________________  Lan  Wireless 
|
|
