轉貼電子報 紅色警戒相關技術內容（1

來源: Hackland <[url]http://hackland.all.at[/url]>
收信: Hackland "地下電子報" "的會員" <[url]http://hackland.all.at[/url]>
日期: 1 Aug 2001 09:45:00 -0000
標題: 紅色警戒相關技術內容（1）




紅色警戒分析資料（1）


--------------------------------------------------------------------------------

看到電視在大肆報導有關這個「紅色警戒」（code red）病毒的相關消息，我想有很多網友會想知道這個病蟲 Worm 的詳細內容，所以我將 eEye 的分析轉貼如下，這個病蟲利用的技術就是之前一個 IIS的「緩衝區溢位」的漏洞（嘿！又是「緩衝區溢位」的問題），我發現我沒有介紹過這個漏洞，可能會找時間我自己寫一篇中文的介紹吧.......


--------------------------------------------------------------------------------

原始資料來源︰http://www.eeye.com/html/Research/Advisories/AL20010717.html

.ida "Code Red" Worm

Release Date:
July 17, 2001

Severity:
HIGH

Systems Affected:
Unpatched Microsoft IIS Web Servers

Description:
On Friday, July 13th we received packet logs and information from two network administrators that were experiencing large amounts of attacks targeting the recent .ida vulnerability that eEye Digital Security discovered ([url]http://www.eeye.com/html/Research/Advisories/AD20010618.html[/url]) on June 18, 2001.

From the first analysis of the logs that were sent to us we were able to deduce that someone had released a worm for the .ida vulnerability. Within the logs we could see connection attempts from over five thousand IIS 5 Web servers targeting various other IIS Web servers and sending an .ida exploit to each of them. Evidence also showed that compromised hosts were being used to attack other hosts.

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. Deep Analysis
4. Conclusion
5. Appendix
6. Credits

You can get a copy of this analysis, commented disassembly, full IDA database, and binary of the worm from

[url]http://www.eeye.com/html/advisories/codered.zip.[/url]

Introduction
============
On Friday, July 13th we received packet logs and information from two network administrators whose servers were experiencing large amounts of attacks targeting the recent .ida vulnerability that eEye Digital Security discovered ([url]http://www.eeye.com/html/Research/Advisories/AD20010618.html[/url]) on June 18, 2001. After reviewing the logs sent to us, we determined that someone had released a worm into the Internet, and it was spreading rapidly through IIS Web servers.

The full analysis of the .ida "Code Red" worm provides numerous details as to the functionality and method of propagation of this worm. For instance the worm's purpose ultimately seems to be to perform a denial-of-service attack against [url]www.whitehouse.gov.[/url] Also, 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, first because part of the worm is designed to deface Web pages with the text "Hacked by Chinese" and second because "Code Red" Mountain Dew was the only thing that kept us awake while we disassembled this exploit.


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 last month.

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 100 threads of the worm.
3. Use the first 99 threads to spread the worm (infect other Web servers).
- The worm spreads itself by creating a sequence of random IP addresses. However, the worm's list of IP addresses to attack is not all together random. In fact, there seems to be a static seed (a beginning IP address that is always the same) that the worm uses when generating new IP addresses. Therefore every computer infected by this worm is going to go through the same list of "random" IP addresses. Because of this feature, the worm will end up re-infecting the same systems multiple times, and traffic will cross traffic back and forth between hosts ultimately creating a denial-of-service type effect. The denial-of-service will be due to the amount of data being transferred between all of 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 many more systems much faster. We are not sure why this 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 to be scanned, then they could setup a "sniffer" and anytime and IP address tried to connect to port 80 on their server they would get confirmation that the IP address that connected to them was infected with the worm. With this knowledge, they would 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 an English (US) Windows NT/2000 system.
- If the infected system is found to be a English (US) system, the worm will proceed to deface the infected system's website. The local Web server's Web page will be changed to a message that says: "Welcome to [url]http://www.worm.com[/url]!, Hacked By Chinese!". This hacked Web page message will stay "live" on the Web server for 10 hours and then disappear. The message will not appear again unless the system is re-infected by another computer.
- If the system is not an English (US) Windows NT/2000 system, 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, each thread will continue to attempt to infect more systems.
6. Each worm thread checks the infected computer's system time.
- If the date is past the 20th of the month (GMT), the thread will stop searching for systems to infect and will instead attack [url]www.whitehouse.gov.[/url] The attack consists of the infected system sending 100k bytes of data (1 byte at a time + 40 bytes overheard for the actually TCP/IP packet) to port 80 of [url]www.whitehouse.gov.[/url] This flood of data (410 megabytes of data every 4 and a half hours per instance of the worm) would potentially amount to a denial-of-service attack against [url]www.whitehouse.gov.[/url]
- If the date is between the 1st and the 19th of the month, this worm thread will not attack [url]www.whitehouse.gov[/url] and will continue to try to find and infect new Web servers.

We have calculated that the worm can attempt to infect roughly half a million IP addresses a day. This is a rough estimate generated by testing on a very slow network.

At the time of writing this document (July 19th, 3:00pm), we have had reports from administrators that have been probed by over 196 thousand unique hosts. This leads us to believe that this worm has infected at least 196 thousand computers.

During testing we noticed that sometimes the worm does not execute "normally" and will continue to spawn new threads until the infected machine crashes and has to be rebooted, effectively killing itself. We have not been able to isolate the cause of this behavior.


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 on our website at [url]http://www.eeye.com/html/advisories/codered.zip.[/url] It is provided as both an assembly text dump and as an IDA (Interactive Disassembler) database file.

Note: We will use CODEREF comments in the following analysis to reference locations in the disassembled code so the reader can follow along while reading.

The tools that we used to perform this detailed analysis are:
- IDA (Interactive Disassembler) from [url]www.datarescue.com.[/url] 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.

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 down the functionality of the worm into three parts: the core worm functionality, the worm hack Web page functionality, and the attack [url]www.whitehouse.gov[/url] 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 an HTTP GET request that contains the necessary code to exploit the ..ida attack. The worm is used as the attack's payload.

At the time of the .ida overflow, a system's 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 is an address within msvcrt.dll. The code at 0x7801CBD3 disassembles to:
call ebx
When EIP is overwritten with call ebx, it causes program flow to divert back to the stack. The code on the stack jumps into the worm code that is 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 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. This allows the worm to generate the function addresses at run time (this gives the worm a better chance of executing cleanly on other systems).

The worm uses a technique called an RVA (Relative Virtual Addresses) lookup. 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. All other functions that the worm may need can be easily found between these two functions. 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 appears to perform a WriteClient (Part of the ISAPI Extension API), sending "GET" back to the attacking worm. This could possibly be a way of telling other 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 below 100 then the worm creates a new thread. Each new thread is an exact replica of the worm (using the same code base). If the number of threads is 100 then control is shifted to the worm hack web page functionality.

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 built in "lysine deficiency" (See Jurassic Park, or Caesar's paper on this at [url]www.rootkit.com[/url]). 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 system's time (computer clock).
CODEREF: seg000:00000803 NOTWORM_NO

The worm checks the infected system's local date (in UTC). If the date is greater than 20 UTC, the worm will proceed to the first step of the attack [url]www.whitehouse.gov[/url] functionality.

If the date is less than 20 UTC, the worm will 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 on which it can find an open port 80 to connect to. 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 Web page functionality
-------------------------------
This functionality is called after one hundred threads are spawned within the worm.

1. Check if local system default language is English US, then go to 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, the worm will proceed to deface the local system's Web page. If the local codepage is not English (US), the worm thread will go to step 6 of core worm functionality.

2. Sleep for two hours.
CODEREF: seg000:00000636 IS_AMERICAN

This worm thread now sleeps for two hours. We anticipate that this is built in to allow the other worm threads to attempt to spread the infection before making its presence known via defacing the infected system's Web page.

3. Attempt to modify infected systems' Web pages in memory.
CODEREF: seg000:0000064F HACK_PAGE

This worm uses an interesting technique called "hooking" to effectively deface (alter) an infected system's Web pages. "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", the worm first makes the first 4000h bytes of w3svc.dll's memory writeable. 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 writeable, saving the old state to a stack variable.

The worm then uses the saved codebase of w3svc.dll (from step 3 of core worm functionality) as a starting 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 from within the worm.

The address that TcpSockSend points to after the change is a function within the worm that will return the "Hacked by Chinese!" Web page. The CODEREF for this function is seg000:00000C9A FAKE_TCPSOCKSEND.

This thread of the worm now sleeps for ten hours. During this ten hours all Web requests to the infected server will return the "Hacked by chinese!" Web page.

After the ten hours is up, this thread will return w3svc.dll to its original state, including re-protecting memory.

Execution then proceeds to step 6 of the core worm functionality.


Attack [url]www.whitehouse.gov[/url] functionality
---------------------------------------
Sooner or later every thread within the worm seems to shift its attacking focus to [url]www.whitehouse.gov.[/url]

1. Create socket and connect to [url]www.whitehouse.gov[/url] on port 80 and send 100k bytes of data (1 byte at a time).
CODEREF: seg000:000008AD WHITEHOUSE_SOCKET_SETUP

Initially the worm will create a socket and connect to 198.137.240.91 ([url]www.whitehouse.gov/www1.whitehouse.gov[/url]) 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 [url]www.whitehouse.gov.[/url]

CODEREF: seg000:00000972 WHITEHOUSE_SLEEP_LOOP
After 18000h SEND()'s the worm will sleep for about four and a half hours. It will then repeat the attack against [url]www.whitehouse.gov[/url] (go to step 1 of attack [url]www.whitehouse.gov[/url] 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:
[url]http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS01-033.asp[/url]
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.

SecureIIS, Application Firewall - Stops known and unknown IIS vulnerabilities. [url]http://wwww.eeye.com/SecureIIS.[/url] 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 go to the Microsoft security site, as referenced above, and install the .ida patch as soon as possible. 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 from 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, install it 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?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0
Just add the above to your IDS signature database. (Line breaks were added between the N's for ease-of-reading on this page. Please remove them prior to updating your signature database).


What are some common misconceptions about the "Code Red" worm?
------------------------------------------------------------
1. It connects to worm.com.
This worm only specifies [url]www.worm.com[/url] in the initial HTTP GET request HOST: header and in the defaced page shown on English (US) systems. This worm does NOT connect to [url]www.worm.com.[/url] This worm operates completely independent and can spread and infect systems without having a single point of failure. This means that the worm will be wild on the Internet until most of the vulnerable systems are patched.

2. This worm is based on hsj's "proof of concept" .ida exploit.
This worm is NOT based on 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 quickly.



微軟官方修補資訊︰
MS01-033 - Unchecked Buffer in Index Server ISAPI Extension Could Enable Web Server Compromise

eEye官方漏洞資訊︰
[url]http://www.eeye.com/html/Research/Advisories/AD20010618.html[/url]


--------------------------------------------------------------------------------