[NEWS] Continued Threat of the "Code Red" Worm
From: support@securiteam.comDate: 07/30/01
- Next message: support@securiteam.com: "[NT] Snapstream PVS Security Vulnerability"
- Previous message: support@securiteam.com: "[NT] Malformed RPC Request Can Cause Service Failure (Exchange, SQL, Windows)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Subject: [NEWS] Continued Threat of the "Code Red" Worm Message-Id: <20010730071009.66891138BF@mail.der-keiler.de> Date: Mon, 30 Jul 2001 09:10:09 +0200 (CEST)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
Continued Threat of the "Code Red" Worm
------------------------------------------------------------------------
SUMMARY
Since around July 13, 2001, at least two variants of the self-propagating
malicious code "Code Red" have been attacking hosts on the Internet.
Different organizations who have analyzed "Code Red" have reached
different conclusions about the behavior of infected machines when their
system clocks roll over to the next month. Reports indicate that there are
a number of systems with their clocks incorrectly set, so CERT believes
the worm will begin propagating again on August 1, 2001 0:00 GMT. There is
evidence that tens of thousands of systems are already infected or
vulnerable to re-infection at that time. Because the worm propagates very
quickly, it is likely that nearly all vulnerable systems will be
compromised by August 2, 2001.
The CERT/CC has received reports indicating that at least 280,000 hosts
were compromised in the first wave.
DETAILS
Vulnerable systems:
* Microsoft Windows NT 4.0 with IIS 4.0 or IIS 5.0 enabled and Index
Server 2.0 installed
* Windows 2000 with IIS 4.0 or IIS 5.0 enabled and Indexing services
installed
* Cisco CallManager, Unity Server, uOne, ICS7750, Building Broadband
Service Manager (these systems run IIS)
* Unpatched Cisco 600 series DSL routers
The "Code Red" worm is malicious self-propagating code that exploits
Microsoft Internet Information Server (IIS)-enabled systems susceptible to
the vulnerability described in
<http://www.securiteam.com/windowsntfocus/5FP0B2K4KU.html> Buffer Overflow
In IIS Indexing Service DLL. Its activity on a compromised machine is time
senstive; different activity occurs based on the date (day of the month)
of the system clock. The CERT/CC is aware of at least two major variants
of the worm, each of which exhibits the following pattern of behavior:
* Propagation mode (from the 1st - 19th of the month): The infected host
will attempt to connect to TCP port 80 of randomly chosen IP addresses in
order to further propagate the worm. Depending on the configuration of the
host that receives this request, there are varied consequences.
* Unpatched IIS 4.0 and 5.0 servers with Indexing service installed will
almost certainly be compromised by the "Code Red" worm. In the earlier
variant of the worm, victim hosts with a default language of English
experienced a defacement on all pages requested from the web server. Hosts
infected with the later variant did not experience any change in the
served content.
* Unpatched Cisco 600-series DSL routers will process the HTTP request
and trigger an unrelated vulnerability that causes the router to stop
forwarding packets. [
<http://www.cisco.com/warp/public/707/cisco-code-red-worm-pub.shtml>
http://www.cisco.com/warp/public/707/cisco-code-red-worm-pub.shtml]
* Systems not running IIS, but with an HTTP server listening on TCP port
80 will probably accept the HTTP request, return with an "HTTP 400 Bad
Request" message, and potentially log this request in an access log.
* Flood mode (from the 20th - 27th of the month): A packet-flooding
denial-of-service attack will be launched against a specific IP address
embedded in the code.
* Termination (after the 27th day): The worm remains in memory but is
otherwise inactive.
Solutions:
Apply patches as described in our previous advisory:
<http://www.securiteam.com/windowsntfocus/5FP0B2K4KU.html> Unchecked
Buffer in Index Server ISAPI Extension Leads to Web Server Compromise
Compromised hosts should refer to CERT's:
<http://www.cert.org/tech_tips/win-UNIX-system_compromise.html > Steps
for Recovering from a UNIX or NT System Compromise
Good Practices:
Consistent with the security best-practice of denying all network traffic
and only selectively allowing that which is required, ingress and egress
filtering should be implemented at the network edge. Likewise, controls
must be in place to ensure that all software used on a network is properly
maintained.
Ingress filtering
Ingress filtering manages the flow of traffic as it enters a network under
your administrative control. Servers are typically the only machines that
need to accept inbound connections from the public Internet. In the
network usage policy of many sites, there are few reasons for external
hosts to initiate inbound connections to machines that provide no public
services. Thus, ingress filtering should be performed at the border to
prohibit externally initiated inbound connections to non-authortized
services. In this fashion, the effectiveness of many intruder scanning
techniques can be dramatically reduced. With "Code Red," ingress filtering
will prevent instances of the worm outside of your network from infecting
machines in the local network that are not explicitly authorized to
provide public web services.
Egress filtering
Egress filtering manages the flow of traffic as it leaves a network under
your administrative control. There is typically limited need for machines
providing public services to initiate outbound connections to the
Internet. In the case of "Code Red," employing egress filtering will
prevent compromised IIS servers on your network from further propagating
the worm.
Installing new software with the latest patches
When installing an operating system or application on a host for the first
time, it is insufficient to merely use the install media. Vulnerabilities
are often discovered after the software becomes widely distributed. Thus,
prior to connecting this host to the network, the latest security patches
for the software should be obtained from the vendor and applied.
ADDITIONAL INFORMATION
The information has been provided by <mailto:cert@cert.org> CERT.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Next message: support@securiteam.com: "[NT] Snapstream PVS Security Vulnerability"
- Previous message: support@securiteam.com: "[NT] Malformed RPC Request Can Cause Service Failure (Exchange, SQL, Windows)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
