CODERED.A

This worm and its variant CODERED.B pose minimal risk to most PCs. It uses a remote buffer overflow vulnerability in Internet Information Service (IIS) Web Servers that can give system-level privileges to a remote user, thereby compromising network security.

This worm has two trigger dates and two payloads. The first payload is triggered when the current system day is between the 20th and 28th of the month. This worm executes a distributed denial of service attack (DDoS) on a Government Web site.

The second payload is triggered if the current system day is less than the 20th of the month. The payload then executes and generates random IP addresses and sends copies of itself through port 80.

NOTES:

This worm contains a download command that accessses the Indexing Service (IDA) for the Internet Server API (ISAPI) with parameters greater than the allowed size, and arrives in the packet data. The IIS (Internet Information Service) attempts to process the bulk of the data, which then causes buffer overflow.

The data contains the preferred address used to replace the system instruction pointer during the overflow. It also contains an executable binary code known as the shell code. The buffer overflow allows the execution of the shell code with system level privilege.

Information about this exploit is available at Microsoft Technet and the eEye Digital Security Web site.

This worm searches for a KERNEL32.DLL file where the kernel image is located in an operating system. It then searches for a GetProcAddress API and other APIs or functions it needs for propagation. Aside from the kernel, it needs the following three libraries to function properly:

• INFOCOMM.DLL IIS Common DLL
• W3SVC.DLL (IIS core engine) Web Services
• WS2_32.DLL Winsock V 2.0

When the binary code executes, it spawns 99 threads. These threads share the worms code thus the worm makes several copies of itself. Each spawned copy of the worm checks for the file C:\NOTWORM. If this file exists, the worm becomes dormant. This is achieved by sleeping, or calling the Sleep() API, for 24.85 days and performing another sleep routine when it wakes up. If the file does not exist, it checks the system date for its payloads. It executes a DDOS attack if the system day is between the 20th to 28th of the month. If the current day is before the 20th of the month, the worm sends copies of itself to other computers. If the system day is beyond the 28th, the worm becomes dormant or inactive.

In the DDoS attack, the worm opens and connects to the IP address 198.137.240.91 (www1.whitehouse.gov), where it sends 96KB of random data. The worm thread sleeps for 1 second after each byte is sent. After all data is sent, the worm sleeps for 4.66 hours and repeatedly checks the conditions for payload execution.

To execute the payload when the date is before the 20th, the worm generates random IP addresses and sends copies of itself via Port 80. If successful, a copy of the worm is sent to the address. The worm prevents re-infection by filtering which IP addresses are processed. The worm will not process IP addresses in the form of 127*.*.* and 224.*.*.*. By not processing the first form, the worm avoids the loop back function.

After spawning itself, the worm (or the 100th thread of the worm) checks the default language ID of the system. If it is equal to 1033 or English, the worm changes the local Web page of the server. Otherwise, the worm continues checking the payload conditions and infecting other computers.

To modify the local Web page of the server, the worm patches the import address of the TcpSockSend() API in W3SVC.DLL in memory. Before altering the address, the worm sleeps for two hours. The old address of the API is saved by thread and the patched address now calls a code within the worm. The TcpSockSend() API is used by W3SVC.DLL to send data to clients. After the worm has patched the API, clients who request the servers local Web page receive a page with the following data:

Welcome to http://www.worm.com !

Hacked By Chinese!

After the worm successfully patches the API, it sleeps for 10 hours. When it wakes up, it restores the APIs original address. In the event of patching the API address in the import table, the memory page that contained this information needs to be unprotected. When the API address is restored, the page is also restored, by protecting it again.