Fwd: Handler's Diary 07-19-2001

Matt Fearnow matt at incidents.org
Thu Jul 19 23:59:11 GMT 2001


>Mailing-List: contact intrusions-help at incidents.org; run by ezmlm
>X-No-Archive: yes
>List-Post: <mailto:intrusions at incidents.org>
>List-Help: <mailto:intrusions-help at incidents.org>
>List-Unsubscribe: <mailto:intrusions-unsubscribe at incidents.org>
>List-Subscribe: <mailto:intrusions-subscribe at incidents.org>
>Delivered-To: mailing list intrusions at incidents.org
>Delivered-To: moderator for intrusions at incidents.org
>Date: Thu, 19 Jul 2001 18:55:25 -0500
>From: Vicki Irwin <vicki at incidents.org>
>Reply-To: vicki at incidents.org
>X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
>X-Accept-Language: en
>To: intrusions at incidents.org
>Subject: Handler's Diary 07-19-2001
>
>Incidents.org Handler's Diary
>July 19, 2001
>
>THREAT LEVEL: ORANGE
>
>==========================================================
>
>Updated Statistics of IIS CODE RED Worm Spread
>-------------------------------------------
>
>Ken Eichman of cas.org has furnished us with an updated set of
>statistics for the numbers of independent IP addresses scanning his
>site on port 80. Ken's numbers provide a reasonable indicator of the
>infection rate for this worm. His report is below:
>--------------------
>
>Date       # Worm Probes    # Unique Source Addr's  # Unique Source Addr's
>                              Probing (For the Day)   Probing (Cumulative)
>-----      -------------    ----------------------  ----------------------
>07/13            611                 27                      27
>07/14          36273               1076                    1079
>07/15         215020               3498                    3641
>07/16         316828               6137                    7146
>07/17         316359               7189                   10212
>07/18         294345               8247                   13866
>07/19 *       288975 *            34352 *                 43120 *
>
>* numbers as of 12:00 EDT
>
>----------------------
>Ken also broke down the total number of worm probes
>detected by his IDS today during the hours (EDT) shown:
>
>Here is an hour-by-hour breakdown of the CODE RED worm scans
>targeting Ken's networks as logged by his IDS. The numbers
>are not cumulative - they reflect only the activity during that
>hour.
>
>The "hour" column reflects EDT time (GMT-4) today, 07/19.
>
>                                 # Unique Source Addresses
>Hour    # Code Red Worm Scans     Scanning During the Hour
>------  ---------------------   -------------------------
>  00           12699                     2450
>  01           13059                     2577
>  02           13272                     2590
>  03           13056                     2564
>  04           13283                     2632
>  05           13229                     2612
>  06           13554                     2601
>  07           13517                     2608
>  08           13746                     2685
>  09           16819                     3325
>  10           36589                     7838
>  11          116083                    26823
>  12          295348                    68085
>  13          466542                   103522
>  14          520973                   113451
>  15          513513                   115124
>  16          513894                    90931
>  17          499642                   111175
>  18          480850                   106215  <<<<
>
>Note the drastic increase in the number of probes around 11:00 EDT.
>------------------------------
>
>Ken sent another note around 15:30 EDT, part of which
>is reproduced below below:
>
>" In the 3 hours between 12:00 EDT and 15:00 EDT our class-b was
>   targeted by worm probes from 186,034 unique source IP addresses.
>   That is not a typo: 186,034 hosts in 3 hours. On the plus side it
>   seems to have plateaued as of 14:00 EDT."
>
>----------------------------
>
>Johannes Ullrich has compiled statistics from the DSheild
>database (http://www.dshield.org) about the port 80 scanning
>activity:
>
>+----------+------------+----------+-----------+
>| Total #  |    Date    | # Unique | # Unique  |
>|  Records |            | Src IPs  | Dest IPs  |
>+----------+------------+----------+-----------+
>|     4388 | 2001-07-12 |   893    |      80   |
>|     6727 | 2001-07-13 |   775    |    2501   |
>|    19600 | 2001-07-14 |  1401    |    1324   |
>|   186684 | 2001-07-15 |  3672    |    1998   |
>|   346729 | 2001-07-16 |  6677    |    3679   |
>|   355955 | 2001-07-17 |  7785    |    9751   |
>|   259758 | 2001-07-18 |  9061    |    3232   |
>|   168196*| 2001-07-19*|  6778*   |    2740*  |
>+----------+------------+----------+-----------+
>
>* Complete data for 2001-07-19 not yet available.
>
>=========================================================
>Additional Information about CODE RED Worm
>-------------------------------------------
>A NewsBytes article about the CODE RED worm targeting
>the Whitehouse starting on July 20th UTC is here:
>http://www.newsbytes.com/news/01/168147.html
>More details about this aspect of the worm code is
>described later in today's diary.
>
>Yesterday evening Marc Maiffret posted a detailed analysis
>of the IIS Code Red worm. It may be found at
>http://www.eeye.com/html/advisories/codered.zip
>along with the full disassembled and commented worm code,
>and the worm binary. An overview of Mr. Maiffret's results
>is given in the next section of this diary.
>
>Another interesting read, also by Marc Maiffret of eEye,
>is the original June 19 article that describes the exact
>details of how the .ida buffer overflow may be exploited.
>http://neworder.box.sk/showme.php3?id=4991
>
>In case anyone missed it, but was interested, this link
>points to some proof-of-concept source code that exploits
>the IIS buffer overflow vulnerability.
>http://www.geocities.co.jp/MotorCity/5319/iis5idq_exp.txt
>
>And, most importantly, read what Microsoft has to say
>about the problem and get the patch.
>http://www.microsoft.com/technet/security/bulletin/MS01-033.asp
>
>=========================================================
>CODE RED Infection Spreading Causes DoS Effects
>------------------------------------------------
>
>According to an incidents.org poster, Tom Liston, the CODE
>RED worm causes the unfortunate side effect of crashing
>Cisco (675/678) DSL CPEs running any CBOS prior to version
>2.4.1. Apparently the problem is caused by the GET request
>that performs the buffer overflow. This request locks up
>any modem with the web management interface enabled.
>
>James Edwards also posted that large ISPs and DSL providers
>(including Qwest) are noticing DoS-type problems.
>
>=========================================================
>Outline of Eeye Detailed Analysis
>----------------------------------------
>Researchers at eEye performed a detailed analysis of the
>CODE RED worm yesterday (link above), and made the interesting
>discovery that the worm includes code designed to flood
>www.whitehouse.gov with data starting tomorrow. An outline
>of the tasks the worm performs upon an infected machine are
>given below.
>
>1. Set up initial worm environment on infected system.
>
>2. Check: Is the number of threads = 100?
>                If yes: go to step 7.
>
>3. Create a new thread. Give the thread an identical
>       copy of the worm code (each thread will run
>       through this identical sequence of events starting
>       at step 2).
>
>4. Check: Does C:\notworm exist?
>                If yes: go dormant.
>
>5. Check: Is the day of the month between 20 and 27 UTC, or later?
>                If between: go to step 11.
>                If later: sleep.
>
>6. Scan random IPs on port 80/tcp and attempt to infect others.
>        If an infection is successful, go to step 4.
>
>7. Check: Is local system default language = English (US)?
>                If no: go to step 4.
>
>8. Sleep for 2 hours.
>
>9. Attempt to modify infected system web pages in memory
>       using "hooking" technique. Display "Hacked by Chinese"
>       webpage for 10 hours.
>
>10. Return system to original state. Go to step 4.
>
>11. Connect to www.whitehouse.gov on port 80.
>       Perform 98304 (=0x18000) 1-byte sends to www.whitehouse.gov.
>
>12. Sleep for 4.5 hours. Upon waking, go to step 11.
>
>
>Notes:
>    o eEye's detailed analysis said that the worm attacks
>        www.whitehouse.gov based on the time. That was later
>        found to be incorrect. The worm makes this decision
>        based on the date, as outlined above. The correction
>        is credited to Eric from Symantec.
>
>    o eEye's analysis says that the worm does not connect
>        to www.worm.com, but only specifies that page in
>        the web page defacement and in in the initial
>        HTTP GET request HOST: header, which is contrary to
>        other earlier reports we have received.
>
>    o The following GET request is the signature of one
>       infected IIS server attempting to infect another.
>
>GET
>/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
>NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
>NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
>NNNNNNNNN%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
>
>===============================================================
>DNS Poisoning Attack Underway : Bigred.com
>--------------------------------------------
>A poster to the incidents.org intrusions list, James Crossman,
>alerted us to the fact that a DNS poisoning attack is currently
>being waged. The result of the poisoning is that all addresses
>that do not resolve normally (e.g. the domain doesn't exist)
>are resolved to bigred.com.
>
>According to a posting by Mike Batchelor to another list, the
>problem comes when a DNS server encounters poison information
>concerning the Generic Top Level Domain Servers [a-m].gtld-servers.net.
>The poison assigns the IP address 66.34.52.224 to all of them.
>
>If the server is running a Windows 2000 DNS server in its
>default setup, or a very old version of BIND (prior to
>approximately v. 4.9.1), the server may cache the false address
>for the GTLD servers. Then, any future queries for GTLD domains
>are directed to 66.34.52.224. When 66.34.52.224 receives an
>iterative query, it will respond with the IP address of the
>bigred.com search engine website.
>
>It is interesting to note that only iterative (as opposed to
>recursive) queries to the bogus server appear to elicit
>this behavior. This makes the situation difficult to debug
>as Mr. Batchelor points out: "Common query tools perform
>recursive queries unless told otherwise. Caches use iterative
>queries to resolve domains for their clients. That these
>poison servers respond with bogus glue only to iterative
>queries is slightly clever, and provides a little cover
>while DNS caches continue to be poisoned."
>
>The solution for Windows 2000 DNS servers is to check the
>box labeled "Secure cache against pollution" on the Properties
>screen of the DNS server control panel (disabled by
>default), and flush the cache.
>
>Mr. Crossman points out that the bogus server does not
>stay static at 66.34.52.224 (that is where it was for
>Mr. Batchelor's investigation), but moves around and
>comes and goes. The best way to see if your cache has
>been poisoned is to check the cache for the
>[a-m].gtld-servers.net, if all these addresses are the
>same, the cache has been poisoned.
>
>=================================================================

Matt Fearnow
SANS Incident Handler
matt at incidents.org

PGP Key Fingerprint:
9285 805F 8947 A2F9 75F6
F1C9 B71D F979 B8B8 7571



More information about the unisog mailing list