__________________________________________________________
The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
__________________________________________________________
ADVISORY NOTICE
Apache/mod_ssl Worm
[CERT® Advisory CA-2002-27]
September 16, 2002 17:00 GMT Number M-125
______________________________________________________________________________
PROBLEM: There have been numerous reports of self-propagating malicious
code which exploits a vulnerability (VU#102795) in OpenSSL.
PLATFORM: Linux systems running Apache with the OpenSSL module (mod_ssl)
on Intel architectures, versions prior to 0.9.6e.
DAMAGE: Exploiting this vulnerability can lead to a compromise at the
apache user level. This worm also has the capabilities to
initiate DDoS attacks using infected systems.
SOLUTION: Upgrade to OpenSSL version 0.9.6e or higher, or apply
available patches.
______________________________________________________________________________
VULNERABILITY The risk is HIGH. This worm is in the wild. CIAC has received
ASSESSMENT: reports of infected and compromised systems. Not only can
exploited systems be used to gain access but they can also be
used for distributed denial of service (DDoS) attacks.
______________________________________________________________________________
LINKS:
CIAC BULLETIN: http://www.ciac.org/ciac/bulletins/m-125.shtml
ORIGINAL BULLETIN: http://www.cert.org/advisories/CA-2002-27.html
PATCHES: http://www.openssl.org/news/patch_20020730_0_9_6d.txt
http://www.openssl.org/news/patch_20020730_0_9_7.txt
______________________________________________________________________________
[***** Start CERT Advisory CA-2002-27 *****]
CERT® Advisory CA-2002-27 Apache/mod_ssl Worm
Original release date: September 14, 2002
Last revised: September 16, 2002 11:19 EDT (UTC-0500)
Source: CERT/CC
A complete revision history can be found at the end of this file.
Systems Affected
Linux systems running Apache with mod_ssl accessing SSLv2-enabled OpenSSL 0.9.6d or
earlier on Intel x86 architectures
Overview
The CERT/CC has received reports of self-propagating malicious code which exploits a
vulnerability (VU#102795) in OpenSSL. This malicious code has been referred to as
Apache/mod_ssl worm, linux.slapper.worm and bugtraq.c worm. Reports received by the
CERT/CC indicate that the Apache/mod_ssl worm has already infected thousands of systems.
I. Description
The Apache/mod_ssl worm is self-propagating malicious code that exploits the OpenSSL
vulnerability described in VU#102795. This vulnerability was the among the topics
discussed in CA-2002-23 Multiple Vulnerabilities In OpenSSL. While this OpenSSL server
vulnerability exists on a wide variety of platforms, the Apache/mod_ssl worm appears to
work only on Linux systems running Apache with the OpenSSL module (mod_ssl) on Intel
architectures.
The Apache/mod_ssl worm scans for potentially vulnerable systems on 80/tcp using an
invalid HTTP GET request.
GET /mod_ssl:error:HTTP-request HTTP/1.0
When an Apache system is detected, it attempts to send exploit code to the SSL service
via 443/tcp. If successful, a copy of the malicious source code is then placed on the
victim server, where the attacking system tries to compile and run it. Once infected,
the victim server begins scanning for additional hosts to continue the worm's
propagation.
Additionally, the Apache/mod_ssl worm can act as an attack platform for distributed
denial-of-service (DDoS) attacks against other sites by building a network of infected
hosts. During the infection process, the attacking host instructs the newly-infected
victim to initiate traffic on 2002/udp back to the attacker. Once this communications
channel has been established, the infected system becomes part of the Apache/mod_ssl
worm's DDoS network. Infected hosts can then share information on other infected systems
as well as attack instructions. Thus, the 2002/udp traffic can be used by a remote
attacker as a communications channel between infected systems to coordinate attacks on
other sites.
Reports to the CERT/CC indicate that the high volume of 2002/udp traffic generated
between hosts infected with the Apache/mod_ssl worm may itself lead to performance
issues on networks with infected hosts. Furthermore, since repairing an infected host
does not remove its IP address from the Apache/mod_ssl worm's Peer-to-Peer network,
sites that have had hosts infected with the Apache/mod_ssl worm and subsequently patched
them may continue to see significant levels of 2002/udp traffic directed at those
formerly infected systems.
Identifying infected hosts
Reports indicate that the Apache/mod_ssl worm's source code is placed in /tmp/.bugtraq.c
on infected systems. It is compiled with gcc, resulting in the executable binary being
stored at /tmp/.bugtraq; therefore, presence of any of the following files on Linux
systems running Apache with OpenSSL is indicative of compromise.
/tmp/.bugtraq.c
/tmp/.bugtraq
The probing phase of the attack may show up in web server logs as shown in the example
below. Actual log entries may vary from system to system, but will generally include an
"SSL handshake failed" followed by an OpenSSL library error. It is important to note
that there may be other causes of such log entries, so the appearance of entries
matching (or similar to) these in a web server log should not be construed as evidence
of compromise. Rather, their presence is indicative that further investigation may be
warranted. For example, :
GET /mod_ssl:error:HTTP-request HTTP/1.0
Reports received by the CERT/CC indicate that Apache systems may subsequently log
messages similar to the following:
[error] SSL handshake failed: HTTP spoken on HTTPS port; trying to send HTML error page
(OpenSSL library error follows)
[error] OpenSSL: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request [Hint:
speaking HTTP to HTTPS port!?]
Hosts found to be listening for or transmitting data on 2002/udp are also indicative of
compromise by the Apache/mod_ssl worm.
Detecting Apache/mod_ssl worm activity on the network
Infected systems are readily identifiable on a network by the following traffic
characteristics:
Probing -- Scanning on 80/tcp
Propagation -- Connections to 443/tcp
DDoS -- Transmitting or receiving datagrams with both source and destination ports
2002/udp. This traffic is used as a communications channel between infected systems to
coordinate attacks on other sites.
Additionally, infected hosts that are actively participating in DDoS attacks against
other systems may generate unusually high volumes of attack traffic using various
protocols (e.g., TCP, UDP, ICMP)
II. Impact
Compromise by the Apache/mod_ssl worm indicates that a remote attacker can execute
arbitrary code as the apache user on the victim system. It may be possible for an
attacker to subsequently leverage a local privilege escalation exploit in order to gain
root access to the victim system. The high volume of 2002/udp traffic generated between
hosts infected with the Apache/mod_ssl worm may itself lead to performance issues on
networks with infected or formerly infected hosts. Furthermore, the DDoS capabilities
included in the Apache/mod_ssl worm allow victim systems to be used as platforms to
attack other systems.
III. Solution
Apply a patch
Administrators of all systems running OpenSSL are encouraged to review CA-2002-23 and
VU#102795 for detailed vendor recommendations regarding patches.
Note that while the vulnerability exploited by the Apache/mod_ssl worm was fixed
beginning with OpenSSL version 0.9.6e, as of this writing the latest version of OpenSSL
is 0.9.6g. Administrators may wish to upgrade to that version instead.
The following is reproduced in part from CA-2002-23
Upgrade to version 0.9.6e of OpenSSL
Upgrade to version 0.9.6e of OpenSSL to resolve the issues addressed in this advisory.
As noted in the OpenSSL advisory, separate patches are available:
Combined patches for OpenSSL 0.9.6d:
http://www.openssl.org/news/patch_20020730_0_9_6d.txt
After either applying the patches above or upgrading to 0.9.6e, recompile all
applications using OpenSSL to support SSL or TLS services, and restart said services or
systems. This will eliminate all known vulnerable code.
Sites running OpenSSL pre-release version 0.9.7-beta2 may wish to upgrade to 0.9.7-
beta3, which corrects these vulnerabilities. Separate patches are available as well:
Combined patches for OpenSSL 0.9.7 beta 2:
http://www.openssl.org/news/patch_20020730_0_9_7.txt
Disable SSLv2
Disabling SSLv2 handshaking will prevent exploitation of VU#102795. CERT/CC recomends
consulting the mod_ssl documentation for a complete description of the options but one
method for disabling SSLv2 is to remove SSLv2 as a supported cipher in the
SSLCipherSuite directive in the configuration file. For example:
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+SSLv2
which allows SSLv2 can be changed to
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:!SSLv2
which will disable SSLv2. Note the changing of +SSLv2 to !SSLv2.
However, systems may still be susceptible to the other vulnerabilities described in CA-
2002-23.
Ingress/Egress filtering
The following steps are only effective in limiting the damage that systems already
infected with the Apache/mod_ssl worm can do. They provide no protection whatsoever
against the initial infection of systems. As a result, these steps are only recommended
in addition to the preventative steps outlined above, not in lieu thereof.
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 traffic from the public Internet. In the network usage policy of many sites,
external hosts are only permitted to initiate inbound traffic to machines that provide
public services on specific ports. Thus, ingress filtering should be performed at the
border to prohibit externally initiated inbound traffic to non-authorized services.
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 the Apache/mod_ssl worm, employing ingress and egress filtering can help
prevent systems on your network from participating in the worm's DDoS network and
attacking systems elsewhere. Blocking UDP datagrams with both source and destination
port 2002 from entering or leaving your network reduces the risk of external infected
systems communicating with infected hosts inside your network.
Recovering from a system compromise
If you believe a system under your administrative control has been compromised, please
follow the steps outlined in
Steps for Recovering from a UNIX or NT System Compromise
Reporting
The CERT/CC is interested in receiving reports of this activity. If machines under your
administrative control are compromised, please send mail to cert@cert.org with the
following text included in the subject line: "[CERT#23820]".
[ DOE sites should report any activity to ciac@ciac.org ]
--------------------------------------------------------------------------------
Feedback can be directed to the author: Allen Householder
--------------------------------------------------------------------------------
This document is available from: http://www.cert.org/advisories/CA-2002-27.html
[***** End CERT Advisory CA-2002-27 *****]
_______________________________________________________________________________
CIAC wishes to acknowledge the contributions of CERT for the
information contained in this bulletin.
_______________________________________________________________________________
CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.
CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
Voice: +1 925-422-8193 (7x24)
FAX: +1 925-423-8002
STU-III: +1 925-423-2604
E-mail: ciac@ciac.org
Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.
World Wide Web: http://www.ciac.org/
Anonymous FTP: ftp.ciac.org
PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins. If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at http://www.first.org/.
This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.
LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)
M-116: Microsoft Cumulative Patch for Internet Explorer
M-117: Microsoft Office Web Components Vulnerabilities
M-118: HP Tru64 Unix Multiple Vulnerabilities
M-119: Cisco VPN 3000 Concentrator Multiple Vulnerabilities
M-120: Microsoft Visual FoxPro 6.0 Vulnerability
M-121: Microsoft Certificate Validation Vulnerability
M-122: Remotely Exploitable Buffer Overflow in PGP
M-123: Polycom Videoconferencing Remote Vulnerabilities
M-124: Konqueror Secure Cookie Vulnerability