|
IIS-Worm.CodeRed (a.k.a. "Code Red", "Bady" Viruses Information
| Name: |
IIS-Worm.CodeRed (a.k.a. "Code Red", "Bady" |
| Category: |
Viruses |
| Description:
|
Details
IIS-Worm.CodeRed (a.k.a. "Code Red", "Bady")
"CodeRed" is an Internet worm that replicates between Windows 2000 servers running Microsoft's IIS (Internet Information Services) and the Microsoft Index Server 2.0 or the Windows 2000 Indexing Service. It does this by exploiting a bug known as "Unchecked Buffer in the Index Server ISAPI Extension," described by Microsoft in the "Microsoft Security Bulletin MS01-033," released on June 18th, 2001.
Using a specially crafted string sent to HTTP servers over the Internet, the worm manages to overwrite a variable in the a module named "idq.dll"; thus, forcing the system to jump to an incorrect address, executing the worm code. When run, the worm code will start to create copies of itself in the memory in order to attack even more IIS servers at the same time. The addresses of the servers that the worms attacks are generated random, but because of a bug, each copy of the worm will try to attack the same list of servers, greatly reducing its overall "attack power."
Apparently, the author also noticed this bug, because a few days after the first variant of the worm appeared in the wild, a second, fixed variant was found as well. This second variant known as ".B" or "v2", generates completely random IP addresses streams, with much higher chances to spread than the initial version.
Interestingly, there's a bug in the worm which causes that instead of 100 expected copies of itself running of every infected machine, much, much more are created, wasting large amounts of CPU and memory resources, thus slowing the server, and again, making the worm replication even less efficient. This bug depends on a lot of factors, and will not always show itself - sometimes, the code will operate as expected, and only create 100 threads.
The main worm payload is run if the current date of the month is between the 20th and 27th, inclusively. Then, it will attempt to connect to an IP address associated with the popular site 'www.whitehouse.gov', and tries to flood it with connection attempts.
Also, the worm attempts to deface web sites running on systems which have the language codepage set to US English. In these cases, the worm tries to deface their look by returning instead pages like the following:
If you are running a vulnerable server, we recommend installing the patch released by Microsoft to fix this problem, which can be downloaded at the following location:
http://www.microsoft.com/technet/security/bulletin/MS01-033.asp
Technical details:
The worm exploits a buffer overflow in the ISAPI component "idq.dll." When a specific string of characters is sent for processing to one of the functions in "idq.dll," a buffer is overflown, causing the CPU to return control from the function to a bogus address, within the worm "loader."
To do this, the worm sends requests that appear as the following:
GET /default.ida?{224 'N' characters here}%u9090%u6858%ucbd3%u7801%u9090 %u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003 %u8b00%u531b%u53ff%u0078%u0000%u00{several headers} {worm code appended from here}
The loader encoded in the above request works on the assumption that in the memory at offset 0x7801CBD3h - usually in the memory space allocated to the code segment of the 'msvcrt.dll' library - there is a two-byte long instruction 'call ebx' that is used to jump to the real worm code. However, this is only true if the system is running the default, out-of-the- box version of Windows 2000, with no Service Pack installed. If the system is running NT4, or Win2K SP1/SP2, the worm will most likely crash the Web server, stopping the IIS WWW service.
However, if the system is running the default Windows 2000 installation, the worm receives control through the jump at 0x7801cbd3, and starts to prepare for its next phases.
For that, it will set up a stack space to be later used by the internal operations of the worm, and will look in the memory for the image of the 'kernel32.dll' module. It will perform this checking incrementally various offsets, and whenever a possible candidate is found, the worm verifies that it's indeed a PE file named 'KERNEL32'. If the checks succeed, the worm parses the 'Kernel32.dll' export table in memory, and obtains the address of the very handy API GetProcAddress, which later is used to fetch even more functions: the "socket", "connect", "send", "recv" and "closesocket" subroutine addresses in "WS2_32.dll", and "LoadLibraryA", "GetSystemTime", "CreateThread", "CreateFileA", "Sleep", "GetSystemDefaultLangID" and "VirtualProtect" from 'Kernel32.dll'.
Next, the worm attempts to spawn 100 copies of itself, using the "CreateThread" API, but because of a programming mistake, it will actually create a lot more. Because of this, a server infected with the worm will most likely have a very high CPU load, unless it runs on an extremely fast machine, with lots of memory.
Each thread run by the worm will first look for a file on the disk named "c:notworm," and if found, it will enter a 'dormant' state, issuing Sleep requests of about 24 days, in an infinite loop. Otherwise, the worm will continue by running one of its two payload subroutines, which check whether the current date of the month is from the 20th to 28th. If so, the worm will attempt to launch connections to the IP address '198.137.240.91', one of the servers hosting the 'www.whitehouse.gov' site. At the time of writing, the respective server seems to have been specifically shut down, and the traffic to the Web site redirected to a different address, probably in an attempt to avoid attacks.
If the current day of the month doesn't match the above rule, the worm attempts to spread itself further. For that, it takes the current second from the system time, and mixes it into a mathematic formula with the thread index in order to produce random numbers suitable for use as IP addresses. However, a bug in the algorithm causes the 'second' field of the time to be ignored; thus, the worm will generate the random numbers only based on the thread index, which is a number between 0 and 99. Therefore, every running copy of the worm will attack the same line of IP addresses, again, a bug which makes the worm less efficient.
To infect servers further, the worm constructs an HTTP request in the memory similar to that used to plant itself initially in the server, and appends its code to it. Then it tries to connect on port 80 to the random IP address provided by the previous subroutine, and if possible, it sends a request to the server. If the respective machine is vulnerable, another copy of the worm will take control, and start doing its job further.
The other worm payload is run only if the codepage of the infected system is 0x409, US English. If so, the worm finds in a specific .DLL module used by the IIS server in the memory, and patches its export table so the 'TcpSockSend' function from it points to a piece of worm code, which instead of the legitimate Web content, it returns a defaced Web site HTML, which looks like the one at the beginning of this description.
After showing the defaced version of the page for 10 hours, the worm reverses the process, and removes itself from the chain of functions used to hijack the Web page, allowing the IIS WWW service to return the proper pages when requested.
"CodeRed.c" (AKA "CodeRedII")
On August 4, 2001, a new variant of the worm was reported in the wild, spreading much faster than the first two variants.
This new variant uses a rather peculiar random IP address generator, which mainly attempts to attack hosts with addresses similar to the one of the host running the worm. For example, if the worm is running on a machine with the address 192.a.b.c, other hosts in the 192.x.x.x family of addresses will have a higher chance of being hit than the others. Apparently, this algorithm had more success than the completely random approach used in the ".A" and ".B" variants of the worm.
Compared to the ".A" and ".B" versions, the newer one is shorter, but on the flip side, it seems to have been written by someone with better knowledge of the i386 assembler. It will also attempt to backdoor an infected system by copying the standard Windows2K command shell processor "cmd.exe" in two of the IIS server directories, and it will also drop and run a Trojan in the root of the "C:" and "D:" drives, named "explorer.exe", 8192 bytes long.
Also, the ".C" variant seems to have been written in response to the "pro-Chinese" ".A" and ".B" versions; if the system language codepage is set either to Traditional or Simplified Chinese, the worm will launch 600 replication threads compared to the default case, where only 300 are run.
Also, on Chinese systems, the worm is allowed to replicate for 48 hours before the system is shutdown. On other machines, the worm runs only for 24 hours, (86,400 seconds) before the system is rebooted.
As mentioned above, the IP random address generator in this variant has been carefully tuned to generate values similar to that of the host on which it is running. With a 1 in 8 probability, the address will be "fully" random, 4 in 8 the address will be in the same Class A family as the one of the system running the worm, and with 3 in 8 chances the randomly generated address will be in the same Class B family as the one of the system running the worm.
Compared to the ".A" and ".B" variants, another improvement in this version is that two main threads of the worm will never run on the same server - a global atom named "CodeRedII" will be set by the first copy of the worm, and any other one will abort execution if the respective atom value is found. Besides that, the worm avoids infecting the machine on which it is running, unlike the first two variants.
This variant of the worm has also a time condition, which is matched after October 2001, when instead of replicating further in an infected machine, the worm will simply reboot the system.
Instructions for deleting the CodeRed II Trojan
1. Click and install the Microsoft patch here:
http://www.microsoft.com/technet/security/bulletin/MS01-033.asp
2. Delete the Trojan from memory in the following way:
2.1 Press CTRL-SHIFT-ESC at the same time to enter "Task Manager";
2.2 Click the "Processes" tab;
2.3 Arrange the process list by names as suits you and click the "Image Name" heading;
2.4 There are two processes in the task list with the names Explorer.exe. In order to recognize the Trojan's process, you must:
2.4.1 In the "View" menu, choose "Select columnall";
2.4.2 Then click on "Thread Count" in the window that appears and click "Ok";
2.5 The number of threads involved in each process will be visible in the additional "Thread" column. The Trojan's process with the Explorer.exe name has only one thread. You must delete this process by:
2.6 Selecting this process;
2.7 Clicking "End process";
2.8 Answering "Yes" to the question;
2.9 Closing the "Task Manager" window.
3. Delete the explorer.exe files from the C: and D: disks' root catalogue. To do this, you must complete the following:
3.1 Click on "My computer" twice;
3.2 Click on C: twice;
3.3 If you don't see explorer.exe, you must do the following:
3.3.1 In the "Tools" menu, select "Folder Options...";
3.3.2 Click on "View";
3.3.3 In "Advanced settings," find and switch on "Show hidden files and folders";
3.3.4 Find and switch on "Hide protect operating system files (Recomended)". Answer "Yes" to the question;
3.3.5 Click "OK," and all hidden files will come into view.
3.4 Delete the explorer.exe file by clicking on it with the mouse and clicking "Del," making sure that the file has been deleted;
3.5 Repeat this in order to delete the file from the D: disk, skipping step 3.3 above.
4. If there are four files related to the Trojan, delete them in the same way:
C:inetpubScriptsRoot.exe
D:inetpubScriptsRoot.exe
C:Program filesCommon FilesSystemMSADCRoot.exe
D:Program filesCommon FilesSystemMSADCRoot.exe
5. It is now necessary to delete the virtual catalogues created by the Trojan by:
5.1 Clicking the right mouse button on "My computer" and selecting "Manage" from the menu;
5.2 In the "Computer Management" window, choose "Computer Services/Services and Applications/Internet Information Services/")
5.3 Select the "C" virtual catalogue and click "Del" and answer "Yes" to the question.
5.4 Do the same with the "D" catalogue.
6. In order to clean out the register, you must do the following:
6.1 Access the register by hitting "Start" and choosing "Run," enter "regedit" and click "Enter."
6.2 Find the key:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3SVCParametersVirtual Roots
6.3 Select the "/C" parameters and click "Del," and answer "Yes" to the question.
6.4 Do the same for the "/D" parameters.
6.5 Click on the "/MSDAC" parameters twice and change the end value to 201.
6.6 Do the same with the "/Scripts" parameters.
6.7 Find the key:
HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinLogon
6.8 Click on the "SFCDisable" parameters twice and change its value to 0.
7. Restart/reboot your computer. |
Top Viruses Visited Pages:
Invader. - 239 visits
not-a-virus:RiskWare.Tool.RegPatch. - 73 visits
Worm.P2P.Harex. - 66 visits
not-a-virus:RemoteAdmin.Win32.RAdmin.2 - 60 visits
Small.58. - 56 visits
Coito.64 - 54 visits
I-Worm.Mapson. - 48 visits
Win32.Hidra - 43 visits
Win16.Klon.1177 - 42 visits
Marine.500 - 35 visits
Random Viruses Pages:
TNSE famil
I-Worm.Hybris.
Calu.242
Win32.Benny.3219.
Viking Famil
SanLorenzo Famil
Win32.Vampiro.701
Backdoor.Netdex.
Ultimatio
MustDie famil
|
