Security News > 2001 > July > Full analysis of the .ida "Code Red" worm.
The following is a detailed analysis of the "Code Red" .ida worm that we reported on July 17th 2001. This analysis was performed by Ryan Permeh and Marc Maiffret of eEye Digital Security. The disassembly (complete with comments) was done by Ryan "Shellcode Ninja" Permeh. Table of Contents ================= 1. Introduction 2. Explanation 3. Commentary 4. Deep Analysis 5. Conclusion 6. Appendix 7. Credits You can get a copy of this analysis, commented disassembly, full IDA database, and binary of worm from http://www.eeye.com/html/advisories/codered.zip Introduction ============ On Friday July 13th we received packet logs and information from 2 network administrators that were experiencing large amounts of attacks targeting the recent .ida vulnerability that eEye Digital Security discovered (http://www.eeye.com/html/Research/Advisories/AD20010618.html) on June 18, 2001. After reviewing the logs sent to us we determined that in fact someone had released a worm into the Internet that was spreading rapidly through IIS web servers. The full analysis of the .ida "Code Red" worm has provided numerous new details as to the functionality and method of propagation of this worm. For instance this worms purpose ultimately seems to be to perform a denial of service attack against www.whitehouse.gov. Also it has been found that only US English Windows NT/2000 systems will show the defaced ("Hacked by Chinese !") web page. We've designated this the .ida "Code Red" worm, because part of the worm is designed to deface web pages with the text "Hacked by Chinese" and also because code red mountain dew was the only thing that kept us awake all last night to be able to disassemble this exploit even further. Explanation =========== As stated earlier the .ida "Code Red" worm is spreading throughout IIS web servers on the Internet via the .ida buffer overflow attack that was published weeks ago. The following are the steps that the worm takes once it has infected a vulnerable web server. 1. Setup initial worm environment on infected system. 2. Setup a 100 threads of the worm 3. The first 99 threads are used to spread the worm (infect other web servers). -The worm spreads itself by creating a sequence of random IP addresses. However, the worm's randomization of IP addresses to attack is not all together random. In fact there seems to be a static seed that the worm uses when generating new IP addresses to try to attack. Therefore every computer infected by this worm is going to go through the same list of random IP addresses to try to infect. The "problem" with that is that the worm is going to end up reinfecting systems and also end up crossing traffic back and forth between hosts to end up creating a denial of service type affect because of the amount of data that will be transferred between all the IP addresses in the sequence of random IP addresses. The worm could have done truly random IP generation and that would have allowed it to infect a lot more systems a lot faster. We are not sure why that was not done but a friend of ours did pose an interesting idea... If the person who wrote this worm owned an IP address that was one of the first hundred or thousand etc... to be scanned then they could setup a sniffer and anytime and IP address tried to connect to port 80 on their IP address they would know that the IP address that connected to them was infected with the worm and they would therefore be able to create a list of the majority of systems that were infected by this worm. 4. The 100th thread checks to see if it is running on a English (US) Windows NT/2000 system. -If the infected system is found to be a English (US) system then the worm will proceed to deface the infected systems website. That means... the local web servers web page will be changed to a message that says Welcome to http://www.worm.com !, Hacked By Chinese!. This hacked web page message will stay "live" on the web server for 10 hours and then disappear and never appear again unless the infected system is re-infected by another host. -If the system is not a English (US) Windows NT/2000 system then the 100th worm thread is also used to infect other systems. 5. Each worm thread checks for c:\notworm -If the file c:\notworm is found, the worm goes dormant. -If the file is not found then each thread will continue to attempt to infect more systems. 6. Each worm thread will now check the infected computers time. -If the time is between 20:00 UTC and 23:59 UTC then the worm will proceed to use this thread to attack www.whitehouse.gov. The attack consists of the infected system sending 100k bytes of data to port 80 of www.whitehouse.gov therefore potentially performing a denial of service attack against www.whitehouse.gov. -If the time is below 20:00 UTC then this worm thread will try to find and infect new web servers. In testing we have calculated that the worm can attempt to infect roughly half a million IP addresses a day and that was a ruff estimate made from using a very slow network. As of writing this document (July 18 6:49pm) we have had reports from administrators that have been probed by over 12 thousand unique hosts. That basically means at least 12 thousand hosts have been infected by this worm. In testing we have seen that sometimes the worm does not execute correctly and will continue to spawn new threads until the infected machine crashes and has to be rebooted. We have not been able to isolate the cause of this behavior. Commentary ========== As we sat and watched this worm spread itself through the Internet we were somewhat dumbfounded as to the number of reported systems being infected. The main reason for that is that this worm is using a, what we thought to be, very well known vulnerability. A patch for this vulnerability has been available for over a month now and at the time of the release of the vulnerability many news agencies ran stories about it therefore trying to spread awareness. Even with all of that though there have still been, at the very least, 12 thousand web servers infected by this worm. So we once again encourage administrators to pay attention to security issues and patch their systems as soon as patches are available for holes. All of this research would not be available if we were not a Full Disclosure company and if the many people who helped us research this worm were against full disclosure. Although we did not release any exploit code for the .ida vulnerability, the computer underground still had no problem creating a devastating worm. In the past we have seen a much higher percentage of patched systems when example exploit code was provided. System administrators do not believe vulnerabilities exist without a public exploit, or until something like this worm happens forcing them to patch their systems. We feel that if the security community moves away from Full Disclosure more incidents like this will happen and everyone will be left in the dark as to what is going on. An example of why full disclosure is so important would be this worm itself. Chances are this worm would have not been discovered if we had not fully disclosed details about the .ida vulnerability, allowing Intrusion Detection System vendors to create signatures for the .ida buffer overflow attack. Because of the way that IIS performs logging (logging a request after processing it), servers hit with this worm will actually have no traces of information left in the IIS log files making tracking this worm (via IIS logs) virtually impossible. The first instances of _anyone_ learning anything useful about this worm was via Intrusion Detection Systems that had signatures based on our .ida vulnerability research which would not have been there if not for full disclosure. The computer underground continues to find vulnerabilities everyday. If full disclosure goes away, then the general security community is left in the dark, and therefore so are administrators. More and more we are seeing an increase in worms attacking the Internet. There have been about 2 or 3 worms in as many months. Worms force computer security to become a global issue. With the rise of the Internet, not only do you have to worry about securing your own systems, you must also be careful of your "neighbors" systems. For instance with this worm even if you have done everything right (installed the .ida patch etc...) your network connection could still be taken down because of the amount of data flooding you from all of the "other guys" who hadn't applied patches and were infected by this worm. It is important to not only maintain your own security but make sure that other people you come in contact with secure their sites. Only with global cooperation to maintain security will the threat of worms start disappear. We received information from "friends" that leads us to believe that this worm is actually a derivative of another worm which was written to exploit the first ever remote IIS buffer overflow (also discovered by eEye Digital Security), the .htr buffer overflow. From reports, the .htr worm had a much smaller infection base and seemed to go under the radar probably because the .htr vulnerability was/is very old. Deep Analysis ============= The following is a very detailed analysis of what the worm is doing at each step of its infection. Full disassembled and commented worm code is available at our website at http://www.eeye.com/html/advisories/codered.zip. It will be provided as both a assembly text dump and as a IDA (Interactive Disassembler) database file. We have chosen not distribute the worm code in this eMail as to not clog up your bandwidth anymore then we already are >:-] Note: We will use CODEREF comments in the analysis to reference where we are in the disassembled code so you can "follow along" with us. The tools that we used to perform this detailed analysis were: IDA (Interactive Disassembler) from www.datarescue.com. IDA is an advanced disassembler that made this analysis possible. MS VC++ debugging environment. We used this to monitor modified pieces of the worm as they interacted with IIS. Ryan's brain + Marc's brain + private eEye tools. No... you cant have any of those. We will be heavily referencing the disassembled worm code in the following analysis. In an attempt to make this easier to understand we have broken the functionality of the worm into 3 parts. The core worm functionality, the worm hack web page functionality and the attack www.whitehouse.gov functionality. Core worm functionality ----------------------- 1. Initial infection vector (i.e. host is vulnerable to the .ida attack and gets hit with this worm). The initial infection starts to take place when a web server, vulnerable to the .ida attack, is hit with a HTTP get request that contains the necessary code to exploit the .ida attack and uses this worm as its payload. At the time of the .ida overflow a systems stack memory will look like the following: 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 92 90 58 68 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 FA 00 00 00 90 90 58 68 D3 CB 01 78 90 90 58 68 D3 CB 01 78 90 90 58 68 D3 CB 01 78 90 90 90 90 90 81 C3 00 03 00 00 8B 1B 53 FF 53 78 EIP is overwritten with 0x7801CBD3 which an address within msvcrt.dll. The code at 0x7801CBD3 disassembles to: call ebx When EIP is overwritten with call ebx it then causes program flow to divert back to the stack. The code on the stack jumps into the worm code that's held in the body of the initial HTTP request. 2. Sets up some initial stack variables CODEREF: seg000:000001D6 WORM At this point we are executing the initial code of the worm. The first thing to happen is that the worm sets up a new stack for its own use. The new stack is 218h bytes, filled with CCh. The worm code then moves on to initialize its function jump table. The entire worm heavily uses an EBP stack based memory offset system. This means that all variables are referenced as EBP-X values. On our website we have a document called worm-ebp.txt that attempts to track stack usage throughout the course of the worm code. 3. Load functions (create the "jump table") CODEREF: seg000:00000203 DataSetup The first thing the worm code does is reference the data portion of the exploit code at EBP-198h. The worm then needs to setup its internal function jump table. A function jump table is a stack based table used to store function addresses. It allows the worm to generate the function addresses at run time (This makes the worm have a better chance of executing cleanly on more systems). The technique used by this worm is what is called an RVA (Relative Virtual Addresses) lookup. Basically this means that all functions, or specifically GetProcAddress, are found within IIS itself. For more details on RVA please consult any good PE (Portable Executable, the executable file format for Microsoft platforms) documentation, or read through the assembly code of this worm. In a nutshell, RVA techniques are used to get the address of GetProcAddress. GetProcAddress is then used to get the address of LoadLibraryA. Between these two functions all other functions that the worm may need can be easily found. The worm uses these two functions to load the following functions: