查看文章 |
承接上一篇，看下预言中即将在愚人节狂飙的东东是个啥玩意儿。 转自“http://mtc.sri.com/Conficker/addendumC/”，省略了一些章节，原因是百度日志长度的限制。
IntroductionThis 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).
Implications of Variant CVariant 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 OverviewFigure 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
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.
省略 In-Situ Analysis - Sandbox OperationsWe used dynamic sandbox monitoring techniques to evaluate the interactions of Conficker C when operating live on the Internet. The release used for this analysis was monitored and filtered such that it would not cause harm to other external hosts while these experiments were being conducted. We describe the network profile of a Conficker C infected host during a 30-minute sandbox execution. Since our current experiments were conducted in early March 2009, we did not see the HTTP rendezvous point lookups. We expect this activity profile to change on 1 April. During our pre 1 April sandbox run, we observed the following network effects, which are illustrated in Figure 9. DNS queries at a rate of 10 to 25 per 5-minute interval were observed. We also observed web server queries, which included connections to 4shared.com, adobe.com, allegro.pl, ameblo.jp, answers.com, aweber.com, badongo.com, baidu.com. bbc.co.uk, blogfa.com, clicksor.com, comcast.net, cricinfo.com, disney.go.com, ebay.co.uk, facebook.com, fastclick.com, friendster.com, imdb.com, megaporn.com, megaupload.com, miniclip.com, mininova.org, ning.com, photobucket.com, rapidshare.com, reference.com, seznam.cz, soso.com, studiverzeichnis.com, tianya.cn, torrentz.com, tribalfusion.com, tube8.com, tuenti.com, typepad.com, ucoz.ru, veoh.com, vkontakte.ru,wikimedia.org, wordpress.com, xnxx.com, yahoo.com, and youtube.com.
P2P queries were sent to random hosts on high-order ports. This is steady at a rate of 50 to 60 hosts per 5 minutes in TCP and a rate of 240 to 2500 hosts per 5 minutes in UDP. The failed TCP and UDP attempts also result in a high rate of inbound ICMP backscatter.
There are also six HTTP connections that were all successfully established in the first 5 minutes to tuenti.com, tianya.cn, miniclip.com, blogfa.com, answers.com and rapidshare.com. In each case, the GET request was to the top directory (GET / HTTP/1.1). Responses are gzip-encoded HTML content.
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/x-ms-xbap, */* Accept-Language: en-GB Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30) Host: rapidshare.com Connection: Keep-Alive
Figure 9: Pre 1 April 2009 short-term network traffic profile
 Figure 10: Post 1 April 2009 6-hour network traffic profile
We also created a new (mutated) version of the binary that executes the post 1 April 2009 logic. The graph in Figure 10 summarizies a long-running (6-hour) network trace of this binary. This figure captures the volumes of observed outbound communication attempts over the multihour run: HTTP, DNS, TCP P2P and UDP P2P, activity. The DNS activity includes two components: attempts to contact the 500 rendezvous points, and attempts to contact Internet portals for finding the date. The trace from this live experimental run corroborates our static analysis results: each C host contacts 500 rendezvous points each day over 116 TLDs with a flat entropy (random domain name space). We see a dropoff in overall levels of DNS activity after hour 3 when it has looked up the IP addresses of all 500 domains. In our case, all these were failed (NXDOMAIN) attempts, as these domains have not yet been registered.
The UDP and TCP P2P activity also drops off in the first 2-hours before settling on a steady scanning rate. The HTTP date check activity remains a relatively steady six to nine hosts contacted per hour. The key implication from the in-situ analysis is that it should be fairly easy to fingerprint Conficker C based upon its unique TCP and UDP scanning patterns. We should also be able to identify C hosts (starting 1 April 2009) based on the volume of NXDOMAIN responses these hosts would receive for failed DNS lookups. ConclusionWe present an analysis of Conficker Variant C, which emerged on the Internet at roughly 6 p.m. (PST) on 4 March 2009. This variant incorporates significant new functionality, including a new domain generation algorithm and a new peer-to-peer file sharing service. Absent from our discussion has been any reference to the well-known attack propagation vectors (RCP buffer overflow, USB, and NetBios Scans) that have allowed C's predecessors to saturate so much of the Internet. Although not present in C, these attack propagation services are but one peer upload away from any C infected host, and may appear at any time. C is, in fact, a robust and secure distribution utility for distributing malicious content and binaries 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. It further demonstrates the rapid development pace at which Conficker's authors are maintaining their current foothold on a large number of Internet-connected hosts. Further, if organized into a coordinated offensive weapon, this multimillion-node botnet poses a serious and dire threat to the Internet. Our report represents one of many Conficker analysis studies going on throughout the whitehat community, and we are in direct contact with numerous groups that will produce additional details, and will help clarify errors that exist in this report. This report is a living document, and we will update it regularly, as our understanding of variant C continues to grow.
AcknowledgmentsWe would like to thank Drew Dean from SRI's Computer Science Laboratory for his assistance in understanding the binary validation routine. We would like to thank Bruce Dang from Microsoft for his assistance in understanding the mutex key generation. We would like to thank Arvind Narayanan from the University of Texas at Austin for his collaboration in the developing the Horizontal Malware Analysis tool shown in Appendix 2.
References
[12] Eric Chien, "Downadup: Peer-to-Peer Payload Distribution," 2009.
[17] CAIDA, "Conficker/Conflicker/Downadup as seen from the UCSD Network Telescope," February 2009. Appendices
Appendix 1 Embedded Strings Within Conficker CWe have extracted and categorized the set of strings that are embedded in the Conficker C binary. The full set of embedded Conficker C strings is listed HERE. Appendix 2 Domain Generator Filtered Address RangesWe have isolated the full set of IP address ranges that are used to prefilter all IP addresses produced by the Conficker C domain generation algorithm. This blocklist is shown HERE. Appendix 3 A Comparative Assessment of Conficker B and C Process ImagesThis is a comparative assessment of the Conficker B++ vs. Conficker C disassembled process images. The complete comparative assessment of B++ vs C is available HERE. Appendix 4 Sandbox Results from Running Conficker CThis appendix shows a forensic analysis of the Conficker C binary as captured through dynamic network analysis and sandbox testing. See the full list of forensic results HERE. Appendix 5 API Recovery TableThis appendix maps the set of obfuscated APIs to their code offsets. The map is useful for a reverse engineering analyst to understand the P2P protocol logic. See the API list HERE. |
