FYI - For those who were following this, here's something to read while eating your peanut butter and jelly sandwich at lunch... -Cameron -------------------- Cameron Childress elliptIQ Inc. p.770.460.1035.232 f.770.460.0963 -- http://www.neighborware.com America's Leading Community Network Software > -----Original Message----- > From: Windows NTBugtraq Mailing List > [mailto:[EMAIL PROTECTED]]On Behalf Of Marc Maiffret > Sent: Thursday, July 19, 2001 1:43 AM > To: [EMAIL PROTECTED] > Subject: 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: > <MORE 4E 00> > 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: > > >From kernel32.dll: > GetSystemTime > CreateThread > CreateFileA > Sleep > GetSystemDefaultLangID > VirtualProtect > > >From infocomm.dll: > TcpSockSend > > >From WS2_32.dll: > socket > connect > send > recv > closesocket > > Finally the worm stores the base address of w3svc.dll which it will later > use to potentially deface the infected website. > > 4. Check the number of threads the worm has created. > CODEREF: seg000:00000512 FUNC_LOAD_DONE > > Here the worm seems to perform a WriteClient (Part of the ISAPI Extension > API), sending "GET" back to the attacking worm. This possibly > could be a way > of telling attacking worms that they have successfully infected a > new host. > > Next the worm code will count the number of worm threads already > in action. > If the number of threads is 100 then control is shifted to the > Worm hack web > page functionality. > > If the number of threads is below 100 then the worm creates a new thread. > Each new thread is an exact replica of the worm (Using the same > code base). > > The worm now continues its path of execution. > > 6. Checks for the existence of c:\notworm > CODEREF: seg000:0000079D DO_THE_WORK > > There seems to be a to be built in "lysine deficiency" (See Jurassic Park, > or Caesar's paper on this at www.rootkit.com). A "lysine deficiency" is a > built in check to keep malicious code from spreading further. > > In this case the "lysine deficiency" is a check for the existence of the > file c:\notworm. If this file exists then the worm will become > dormant. This > means it will not attempt to make connections out to other IP addresses to > try to infect. > > If this file does not exist then the worm continues onto the next step. > > 7. Check the infected systems time (computer clock) > CODEREF: seg000:00000803 NOTWORM_NO > > The worm will now check the infected systems local time (in UTC). If the > hour is greater then 20:00 UTC then the worm will proceed to goto > the first > step of the attack www.whitehouse.gov functionality. > > If the time is less than 20:00 UTC then the worm will attempt to > continue to > try to infect new systems. > > 8. Infect a new host (send .ida worm to a "random" IP address on port 80). > > At this point the worm will resend itself to any IP addresses which it can > connect to port 80 on. It uses multiple send()'s so packet traffic may be > broken up. On a successful completion of send, it closes the > socket and goes > to step 6... therefore repeating this loop infinitely. > > > Worm hack webpage functionality > ------------------------------- > This functionality is called after a hundred threads are spawned > within the > worm. > > 1. Check if local system default language is English us then goto > step 6 of > core worm functionality. > CODEREF: seg000:000005FE TOO_MANY_THREADS > > The first thing the worm does is get the local codepage. A codepage > specifies the local operating system language (I.E. English (US), Chinese, > German etc...). It then compares the local codepage against > 0x409. 0x409 is > the codepage for English (US) systems. If the infected system is > an English > (US) system then the worm will proceed to deface the local > systems webpage. > If the local codepage is not English (US) then this worm thread will goto > step 6 of core worm functionality. > > 2. Sleep for 2 hours. > CODEREF: seg000:00000636 IS_AMERICAN > > This worm thread now sleeps for 2 hours. We anticipate that this > is to allow > the other worm threads to attempt to spread the infection before making a > presence known via defacing the infected systems webpage. > > 3. Attempt to modify infected systems webpages in memory. > CODEREF: seg000:0000064F HACK_PAGE > > This worm uses an interesting technique called "hooking" to effectively > deface (alter) an infected systems webpages. Hooking is modifying code in > memory to point to code that the worm provides. In this case the worm is > modifying w3svc.dll to change the normal operation of a function called > TcpSockSend. TcpSockSend is what w3svc.dll (IIS core engine) uses to send > information back to the client. By modifying this, the worm is able to > change data being written back to clients who request web pages of an > infected server. > > To perform hooking, first the worm makes the first 4000h bytes of > w3svc.dll's memory writable. In a normal situation the memory for > w3svc.dll > (and basically all mapped dll's) is read-only. It uses the function > VirtualProtect to change the memory of w3svc.dll to be writable, > saving the > old state to a stack variable. > > It then uses the saved codebase of w3svc.dll (from step 3 of core worm > functionality) as a start point to search the import table (again see PE > header documentation) for the address of TcpSockSend. Once the address for > TcpSockSend is located the worm then replaces TcpSockSend's actual address > with an address within the worm. > > The address that TcpSockSend now points to is a function within the worm > that will return the "Hacked by Chinese !" webpage. The CODEREF for this > function is seg000:00000C9A FAKE_TCPSOCKSEND. > > This thread of the worm now sleeps for 10 hours. During this 10 hours all > web requests to the infected server will return the "Hacked by chinese !" > webpage. > > After the 10 hours is up this thread will return w3svc.dll to its original > state, including re-protecting memory. > > Execution after this proceeds to step 6 of the core worm functionality. > > > Attack www.whitehouse.gov functionality > --------------------------------------- > Sooner or later every thread within the worm seems to shift its attacking > focus to www.whitehouse.gov. > > 1. create socket and connect to www.whitehouse.gov on port 80 and > send 100k > byes of data > CODEREF: seg000:000008AD WHITEHOUSE_SOCKET_SETUP > > Initially the worm will create a socket and connect to 198.137.240.91 > (www.whitehouse.gov/www1.whitehouse.gov) on port 80. > > CODEREF: seg000:0000092F WHITEHOUSE_SOCKET_SEND > If this connection is made then the worm will create a loop that performs > 18000h single byte send()'s to www.whitehouse.gov. > > CODEREF: seg000:00000972 WHITEHOUSE_SLEEP_LOOP > After 18000h send()'s the worm will sleep for about 4 and a half hours. It > will then repeat the attack against www.whitehouse.gov (goto step one of > Attack www.whitehouse.gov functionality). > > > Appendix > ======== > This is associated information about the "Code Red" worm including how to > stop the worm, commentary on the worm, and dispelling common > misconceptions > about this worm. > > > How to secure your system from this .ida "Code Red" worm? > --------------------------------------------------------- > Microsoft patch for this .ida vulnerability > http://www.microsoft.com/technet/treeview/default.asp?url=/technet > /security/ > bulletin/MS01-033.asp > The worm spreads itself to new vulnerable systems via the .ida > vulnerability. Applying this patch will keep your server from being > infected. However, as stated earlier, because of the way the worm creates > its list of "random" IP addresses to attack, you could still be > affected by > a high traffic overload denial of service. > > eEye Digital Security Advisory for .ida vulnerability > http://www.eeye.com/html/Research/Advisories/AD20010618.html > We initially discovered the .ida vulnerability which is being used by this > worm as its infection vector. The above advisory details our research of > that specific vulnerability. We worked with Microsoft to help > them create a > patch for the .ida vulnerability. > > SecureIIS - Application firewall, stops known and unknown IIS > vulnerabilities. > http://wwww.eeye.com/secureiis > We do produce a product that protects IIS web servers from attack which is > one of the reasons that we were so quick to research this worm. > Funny enough > in our initial testing we couldn't get the worm to work because > we forgot we > had SecureIIS enabled on the lab web server. heh. > > > I have been infected by this worm what can I do? > ------------------------------------------------ > The first thing you must do is goto the Microsoft security site, as > referenced above, and install the .ida patch ASAP. The worm will remain in > memory until you reboot your server so make sure to reboot after > installing > the .ida patch. > > > I think I am infected, how can I tell? > -------------------------------------- > > An infected system will show an increase in load (processor/network). It > will also show a number of external connections (or attempts) to > port 80 of > random IP addresses. You can see this by doing a "netstat -an" > from a MS-DOS > prompt. Either way do not take any chances... if your system is > missing the > .ida patch then install it ASAP and reboot. > > > How to setup your IDS to detect this specific worm? > --------------------------------------------------- > The following is part of the packet data that is sent for this .ida "Code > Red" worm attack: > GET > /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN > NNNNNNNNNN > NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN > NNNNNNNNNN > NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN > NNNNNNNNNN > NNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6 > 858%ucbd3% > u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a > HTTP/1.0 > Just add that to your IDS signature database. > > > What are some common misconceptions about the "Code Red" worm? > -------------------------------------------------------------- > 1. It connects to worm.com. > This worm only specifies www.worm.com in the initial HTTP > GET request HOST: > header and in the defaced page show on English (US) systems. This > worm does > _not_ connect to www.worm.com. This worm operates completely > independent and > can spread and infect systems without having a single point of > failure. What > that means is that this worm will be wild on the Internet until there is a > _VERY_ high degree of systems that go and install the .ida patch. > > 2. This worm is based off of hsj's "proof of concept" .ida exploit. > This worm is _NOT_ based off of hsj's "proof of concept" > .ida exploit. His > exploit code had no worm functionality. It was a simple exploit shell that > had little to no implicit functionality. It was designed to prove to > administrators the seriousness of this vulnerability so that they would > install patches ASAP. > > > Credits > ======= > Ken Eichman of Chemical Abstracts Service > Matthew Asham of Left Coast Systems Corp > and a large handful of administrators who gave us much needed > data to piece > this together. > > Signed, > eEye Digital Security > T.949.349.9062 > F.949.349.9538 > http://eEye.com/Retina - Network Security Scanner > http://eEye.com/Iris - Network Traffic Analyzer > http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities > > "Its not a virus! Its a worm!" - z3r0 c00l > "Whats this one eat?" - l0rd n1k0n > "th1s 0n3 34ts 11S s3rv3rs!" - ch4m3l30n > h4ck3rs > > ------------------------------------------------------------------ > ---------- > Delivery co-sponsored by Trend Micro > ================================================================== > ========== > TREND MICRO REAL-TIME VIRUS ALERTS > If you would like to know about a virus outbreak before CNN and ZDNet get > Trend Micro Virus Info Feed FREE. Simply copy and paste a small piece of > code to give your visitors a real-time top 10 list and the latest virus > advisories. Setup takes just 10 minutes and requires no > server-side code on > your Web site. All content is updated automatically from Trend Micro's Web > site. > http://www.antivirus.com/banners/tracking.asp?si=8&bi=237&ul=/syndication/ > vinfo/ > ------------------------------------------------------------------ > ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
