Original release date: September 14, 2002<br>
Last revised: October 11, 2002<br>
Source: CERT/CC<br>
<p>A complete revision history can be found at the end of this file.</p>
<br>
<a name="affected"></a>
<h3>Systems Affected</h3>
<ul>
<li>Linux systems running Apache with mod_ssl accessing SSLv2-enabled OpenSSL 0.9.6d
or earlier on Intel x86 architectures
</li>
</ul>
<br>
<a name="overview"></a>
<h2>Overview</h2>
<P>The CERT/CC has received reports of self-propagating malicious code
which exploits a vulnerability (<a
href="http://www.kb.cert.org/vuls/id/102795">VU#102795</a>) 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. There are currently at least three known
variants of this worm in circulation.</p>
<br>
<a name="description"></a>
<h2>I. Description</h2>
<p>The Apache/mod_ssl worm is self-propagating malicious code that
exploits the OpenSSL vulnerability described in <a
href="http://www.kb.cert.org/vuls/id/102795">VU#102795</a>. This
vulnerability was the among the topics discussed in <a
href="http://www.cert.org/advisories/CA-2002-23.html">CA-2002-23
Multiple Vulnerabilities In OpenSSL</a>. 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.</p>
<p>The Apache/mod_ssl worm scans for potentially vulnerable systems on
80/tcp using an invalid HTTP GET request. When a potentially
vulnerable Apache system is detected, the worm attempts to connect to
the SSL service via 443/tcp in order to deliver the exploit code. 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. </p>
<p>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 (newer variants have been reported using
1978/udp or 4156/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, this UDP traffic can be used by a remote attacker as a
communications channel between infected systems to coordinate attacks
on other sites.</p>
<p>Reports to the CERT/CC indicate that the high volume of 1978/udp,
2002/udp, or 4156/udp traffic generated between hosts infected with
the Apache/mod_ssl worm may itself lead to performance issues
(including possible denial-of-service conditions) 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 1978/udp, 2002/udp, or 4156/udp traffic directed at those
formerly infected systems.</p>
<h4>Identifying infected hosts</h4>
<p>During the infection process of the "A" variant of the
Apache/mod_ssl worm, an encoded version of the worm's source code is
placed in <font face="monospace">/tmp/.uubugtraq</font>. This file is
then decoded into <font face="monospace">/tmp/.bugtraq.c</font>,
compiled with <font face="monospace">gcc</font>, and the executable
binary is subsequently stored at <font
face="monospace">/tmp/.bugtraq</font>. More recent variants follow a
similar (but not identical) pattern of infection, and leave behind
different files. Because all three variants exploit the same system
vulnerabilities, it is possible that systems infected with one variant
may also become infected with the others. Therefore, presence of any
of the following files on Linux systems running Apache with OpenSSL is
indicative of compromise.
</p>
<dl>
<dt>Variant "A"</dt>
<font face="monospace">
<dd>/tmp/.uubugtraq</dd>
<dd>/tmp/.bugtraq.c</dd>
<dd>/tmp/.bugtraq</dd>
</font>
<dt>Variant "B"</dt>
<font face="monospace">
<dd>/tmp/.unlock.c</dd>
<dd>/tmp/.update.c</dd>
</font>
<dt>Variant "C"</dt>
<font face="monospace">
<dd>/tmp/.cinik</dd>
<dd>/tmp/.cinik.c</dd>
<dd>/tmp/.cinik.go</dd>
<dd>/tmp/.cinik.goecho</dd>
<dd>/tmp/.cinik.uu</dd>
</font>
</dl>
<p>The probing phase of the attack may show up in web server log as
shown in the example below. 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 <b>not</b>
be construed as evidence of compromise. Rather, their presence is
indicative that further investigation may be warranted.</p>
<p>Example: Initial probe to identify web server software version
</p>
<dl><dd>
<font face="monospace">
GET / HTTP/1.1<br>
</font>
</dd></dl>
<p><i>Note: Based on initial reports received by the CERT/CC, earlier
versions of this Advisory mentioned other SSL error messages that
might be logged on potentially vulnerable hosts. On further analysis,
we have concluded that these log messages were unrelated to the
the Apache/mod_ssl worm. An explanation of one possible cause of
those other mod_ssl error messages was provided by <a
href="#inktomi">Inktomi</a> and appears in <a href="#vendors">Appendix
A</a> below.</i>
</p>
<p>Hosts found to be listening for or transmitting data on 1978/udp
(variant "C"), 2002/udp (variant "A"), or 4156/udp (variant "B") are also
indicative of compromise by the Apache/mod_ssl worm.</p>
<p>In addition to communicating with other infected hosts via
4156/udp, the "B" variant of the Apache/mod_ssl worm creates a backdoor
listening on 1052/tcp.
<h4>Detecting Apache/mod_ssl worm activity on the network</h4>
<p>Infected systems are readily identifiable on a network by the
following traffic characteristics:
<ul>
<li>Probing -- Scanning on 80/tcp</li>
<li>Propagation -- Connections to 443/tcp</li>
<li>DDoS -- Transmitting or receiving datagrams with both source and
destination ports 1978/udp, 2002/udp, or 4156/udp. This traffic is
used as a communications channel between infected systems to
coordinate attacks on other sites.</li>
<li>Backdoor ("B" variant only) -- Listening on 1052/tcp.
</ul>
<p>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)</p>
<br>
<a name="impact"></a>
<h2>II. Impact</h2>
<p> 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 (1978/udp or
4156/udp in newer variants) 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. </p>
<br>
<a name="solution"></a>
<h2>III. Solution</h2>
<h4>Apply a patch</h4>
<p>Administrators of all systems running OpenSSL are encouraged to
review <a
href="http://www.cert.org/advisories/CA-2002-23.html">CA-2002-23</a>
and <a href="http://www.kb.cert.org/vuls/id/102795">VU#102795</a> for
detailed vendor recommendations regarding patches. Additional vendor
information is available in <a href="#vendors">Appendix A</a>
below.</p>
<p>Note that while the vulnerability exploited by the Apache/mod_ssl
worm was fixed beginning with OpenSSL version <a
href="http://www.openssl.org/source/">0.9.6e</a>, as of this
writing the latest version of OpenSSL is <a
href="http://www.openssl.org/source/">0.9.6g</a>. Administrators may
wish to upgrade to that version instead.</p>
<p>The following is reproduced in part from <a
href="http://www.cert.org/advisories/CA-2002-23.html">CA-2002-23</a></p>
<blockquote>
<h4>Upgrade to version 0.9.6e of OpenSSL</h4>
<p>Upgrade to version <a
href="http://www.openssl.org/source/">0.9.6e</a> of OpenSSL to resolve
the issues addressed in this advisory. As noted in the <a
href="http://www.openssl.org/news/secadv_20020730.txt">OpenSSL
advisory</a>, separate patches are available:<BR>
<blockquote>
Combined patches for OpenSSL 0.9.6d:<BR>
<a href="http://www.openssl.org/news/patch_20020730_0_9_6d.txt">http://www.openssl.org/news/patch_20020730_0_9_6d.txt</a>
</blockquote>
After either applying the patches above or upgrading to <a
href="http://www.openssl.org/source/">0.9.6e</a>, recompile all
applications using OpenSSL to support SSL or TLS services, and
restart said services or systems. This will eliminate all known
vulnerable code.
</p>
<p>
Sites running OpenSSL pre-release version 0.9.7-beta2 may wish
to upgrade to <a
href="http://www.openssl.org/source/">0.9.7-beta3</a>, which
corrects these vulnerabilities. Separate patches are available
as well:<BR>
<blockquote>
Combined patches for OpenSSL 0.9.7 beta 2:<BR>
<a href="http://www.openssl.org/news/patch_20020730_0_9_7.txt">http://www.openssl.org/news/patch_20020730_0_9_7.txt</a>
</blockquote>
</p>
</blockquote>
<h4>Disable SSLv2</h4>
Disabling SSLv2 handshaking will prevent exploitation of <a
href="http://www.kb.cert.org/vuls/id/102795">VU#102795</a>. 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 <font
face="monospace">SSLCipherSuite</font> directive in the configuration
file.
For example:
<dl><dd>
<font face="monospace">SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+SSLv2</font>
</dd></dl>
<p>which allows SSLv2 can be changed to</p>
<dl><dd><font face="monospace">SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:!SSLv2</font>
</dd></dl>
which will disable SSLv2. Note the changing of <font face="monospace">+SSLv2</font> to <font face="monospace">!SSLv2</font>.
<p>However,
systems may still be susceptible to the other vulnerabilities described in
<a
href="http://www.cert.org/advisories/CA-2002-23.html">CA-2002-23</a>.</p>
<h4>Ingress/Egress filtering</h4>
<p>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 <b>in addition
to</b> the preventative steps outlined above, not in lieu thereof.</p>
<p>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.</p>
<p>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. </p>
<p>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
ports 1978, 2002 and 4156 from entering or leaving your network
reduces the risk of external infected systems communicating with
infected hosts inside your network.</p>
<h4>Recovering from a system compromise</h4>
<p>If you believe a system under your administrative control has been compromised, please follow the steps outlined in</p>
<dl><dd><a href="http://www.cert.org/tech_tips/win-UNIX-system_compromise.html">Steps for Recovering from a UNIX or NT System Compromise</a></dd></dl>
<h2>Reporting</h2>
<p>The CERT/CC is interested in receiving reports of this activity. If
machines under your administrative control are compromised, please
send mail to <a href="mailto:cert@cert.org?subject=[CERT%2323820]">cert@cert.org</a> with the following text included in the
subject line: "<a href="mailto:cert@cert.org?subject=[CERT%2323820]">[CERT#23820]</a>".</p>
<br>
<a name="vendors"></a>
<h2>Appendix A. - Vendor Information</h2>
<p>This appendix contains information provided by vendors for this
advisory. As vendors report new information to the CERT/CC, we will
update this section and note the changes in our revision history. If a
particular vendor is not listed below, we have not received their
comments.</p>
<a name="apple"></a>
<h4>Apple Computer, Inc.</h4>
<blockquote>
<p>
The vulnerability described in this report has been addressed by
<br>
<ul>
<li><a href="http://www.info.apple.com/usen/security/security_updates.html">Security Update 2002-08-23</a> for Mac OS X 10.2 (Jaguar), and by
<li><a href="http://www.info.apple.com/usen/security/security_updates.html">Security Update 2002-08-02</a> for Mac OS X 10.1.5.
</ul>
</p>
</blockquote>
<!-- end vendor -->
<a name="covalent"></a>
<h4>Covalent Technologies</h4>
<blockquote>
<p>
Covalent Technologies has been informed by RSA Security that the BSAFE
libraries used in Covalent's SSL implementations are potentially
vulnerable to the SSL V2 negotiation issue detailed in VU 102795 and
the related CA-2002-23 and CA-2002-27 advisories. All Covalent
products using SSL are affected. Covalent has product updates and
additional information available at: <a
href="http://www.covalent.net/products/rotate.php?page=110">http://www.covalent.net/products/rotate.php?page=110</a>
</p>
</blockquote>
<!-- end vendor -->
<a name="debian"></a>
<h4>Debian Project</h4>
<blockquote>
The Debian project has released <a
href="http://www.debian.org/security/2002/dsa-136">DSA 136</a> a while
ago which fixes this vulnerability. Here's the link:<BR>
<blockquote>
<a href="http://www.debian.org/security/2002/dsa-136">http://www.debian.org/security/2002/dsa-136</a>
</blockquote>
</blockquote>
<!-- end vendor -->
<a name="inktomi"></a>
<h4>Inktomi</h4>
<blockquote>
<p>As noted in the advisory, server log messages such as
<dl><dd>
<font face="monospace">
GET /mod_ssl:error:HTTP-request HTTP/1.0
</font>
</dd></dl>
do not necessarily indicate access by a compromised system. Any HTTP
request to a port expecting to serve HTTPS requests will generate this
log message. The Inktomi web crawler follows URL links published on
public web pages and is sometimes incorrectly directed to https
servers. The crawler does not use Apache nor mod_ssl (nor any kind of
SSL), so it is not subject to the compromise described in this
advisory. But crawler requests can match two of the listed symptoms of
the Apache/mod_ssl worm:</p>
<ul>
<li>Probing -- Scanning on 80/tcp</li>
<li>Propagation -- Connections to 443/tcp</li>
</ul>
<p>The crawler does not use port 2002 nor UDP. Port 80 access or HTTPS
handshake errors from an Inktomi web crawler do
not represent an attack on your web server. </p>
<p>Inktomi crawler systems have hostnames of the form</p>
<dl><dd>
<font face="monospace">
j[1-9][0-9][0-9][0-9].inktomisearch.com<br>
si[1-9][0-9][0-9][0-9].inktomisearch.com
</font>
</dd>
</dl>
<p>The IP addresses of Inktomi crawler hosts will reverse-DNS resolve to
a name of this form.
</p>
</blockquote>
<!-- end vendor -->
<a name="redhat"></a>
<h4>Red Hat Inc.</h4>
<blockquote>
<p>
Versions of OpenSSL that are not vulnerable to this issue have been
available from Red Hat since 29th July 2002. Customers who have kept their
systems up to date by applying fixes or using the Red Hat Network are not
impacted by this worm.
Updates for all affected Red Hat products are available; details and links
to the individual advisories can be found at
<p><dl><dd>
<a href="http://www.redhat.com/support/alerts/linux_slapper_worm.html">http://www.redhat.com/support/alerts/linux_slapper_worm.html</a>
</dd></dl></p>
</p>
</blockquote>
<!-- end vendor -->
<hr noshade>
<p>Feedback can be directed to the author: <a
href="mailto:cert@cert.org?subject=CA-2002-27%20Feedback%20VU%23102795%20CERT%2323820">Allen Householder</a>
<p></p>
<!--#include virtual="/include/footer_nocopyright.html" -->
<p>Copyright 2002 Carnegie Mellon University.</p>
<p>Revision History
<pre>
September 14, 2002: Initial release
September 16, 2002: Updated details on 2002/udp traffic in Description, Impact sections
September 16, 2002: Clarified example web server log entries in Description section
September 16, 2002: Added Ingress/Egress filtering section to Solutions section
September 17, 2002: Clarified example log entries seen by probed servers
September 17, 2002: Added <a href="#apple">Apple</a> vendor statement made 9/16/2002 1:48:09 PM (UTC-0700)
September 17, 2002: Removed references to "GET /mod_ssl:error:HTTP-request" appearing in server logs
September 17, 2002: Added <a href="#inktomi">Inktomi</a> vendor statement made 9/16/2002 09:16:09 AM (UTC-0700)
September 17, 2002: Added <a href="#covalent">Covalent Technologies</a> vendor statement made 9/16/2002 09:59:00 AM (UTC-0700)
September 19, 2002: Added <a href="#redhat">Red Hat Inc.</a> vendor statement made 2002-09-18 09:44:14 (UTC+0100)
September 23, 2002: Added mention of 1978/udp and 4156/udp in use by newer variants of the worm
September 23, 2002: Added additional details on the "B" and "C" variants of the worm.
October 11, 2002: Added <a href="#debian">Debian</a> vendor statement made 10/08/2002 (DSA-136 posted 07/30/2002)
</pre>
</p>
|