CERT Advisory CA-2002-27 Apache/mod_ssl Worm

From: CERT Advisory (cert-advisory@cert.org)
Date: 09/14/02


Date: Sat, 14 Sep 2002 14:48:53 -0400
From: CERT Advisory <cert-advisory@cert.org>
To: cert-advisory@cert.org


-----BEGIN PGP SIGNED MESSAGE-----

CERT Advisory CA-2002-27 Apache/mod_ssl Worm

   Original release date: September 14, 2002
   Last revised: --
   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.

I. Description

   The Apache/mod_ssl worm is self-propagating malicious code that
   exploits the OpenSSL vulnerability described in VU#102795.
  
     http://www.kb.cert.org/vuls/id/102795

   This vulnerability was the among the topics discussed in CA-2002-23
   "Multiple Vulnerabilities In OpenSSL".

     http://www.cert.org/advisories/CA-2002-23.html

   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.

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:

          GET /mod_ssl:error:HTTP-request HTTP/1.0

   Note that the appearance of this entry in a web server log is not
   indicative of compromise, but is merely evidence of a probe from an
   infected system.

   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!?]

   Actual log entries may vary from system to system, but will generally
   include an "SSL handshake failed" followed by an OpenSSL library
   error.

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

     http://www.cert.org/advisories/CA-2002-23.html
     http://www.kb.cert.org/vuls/id/102795

   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.

           http://www.openssl.org/source/

   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.

Recovering from a system compromise

   If you believe a system under your administrative control has been
   compromised, please follow the steps outlined in

     http://www.cert.org/tech_tips/win-UNIX-system_compromise.html

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]".
     _________________________________________________________________

   Feedback can be directed to the author: Allen Householder
   ______________________________________________________________________

   This document is available from:
   http://www.cert.org/advisories/CA-2002-27.html
   ______________________________________________________________________

CERT/CC Contact Information

   Email: cert@cert.org
          Phone: +1 412-268-7090 (24-hour hotline)
          Fax: +1 412-268-6989
          Postal address:
          CERT Coordination Center
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh PA 15213-3890
          U.S.A.

   CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) /
   EDT(GMT-4) Monday through Friday; they are on call for emergencies
   during other hours, on U.S. holidays, and on weekends.

Using encryption

   We strongly urge you to encrypt sensitive information sent by email.
   Our public PGP key is available from
   http://www.cert.org/CERT_PGP.key

   If you prefer to use DES, please call the CERT hotline for more
   information.

Getting security information

   CERT publications and other security information are available from
   our web site
   http://www.cert.org/

   To subscribe to the CERT mailing list for advisories and bulletins,
   send email to majordomo@cert.org. Please include in the body of your
   message

   subscribe cert-advisory

   * "CERT" and "CERT Coordination Center" are registered in the U.S.
   Patent and Trademark Office.
   ______________________________________________________________________

   NO WARRANTY
   Any material furnished by Carnegie Mellon University and the Software
   Engineering Institute is furnished on an "as is" basis. Carnegie
   Mellon University makes no warranties of any kind, either expressed or
   implied as to any matter including, but not limited to, warranty of
   fitness for a particular purpose or merchantability, exclusivity or
   results obtained from use of the material. Carnegie Mellon University
   does not make any warranty of any kind with respect to freedom from
   patent, trademark, or copyright infringement.
     _________________________________________________________________

   Conditions for use, disclaimers, and sponsorship information

   Copyright 2002 Carnegie Mellon University.

   Revision History
   September 14, 2002: Initial release

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQCVAwUBPYODr6CVPMXQI2HJAQHhbgQAktzDUa8MYdBlGkimk9Qo5oVhnEAAUW1s
gkadeQIwNw+bXhu8bzcbx/5WLK2vS09ivFknNO3WYy2MIDFWTtoct4R3xX/PM5Ad
LB7HKSP6nukMJcTq6vnHTtOzaWQkLgbWgOPMpsPfxrjVG6lz4AnwyqkmmLOrl1NS
YMgTNn0niIk=
=SON1
-----END PGP SIGNATURE-----



Relevant Pages

  • Risks Digest 27.83
    ... ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ... OpenSSL Heartbleed vulnerability ... Experts Find a Door Ajar in an Internet Security Method ...
    (comp.risks)
  • CERT Advisory CA-2002-23 Multiple Vulnerabilities In OpenSSL
    ... There are four remotely exploitable buffer overflows in OpenSSL. ... Several of these vulnerabilities could be used by a remote attacker to ... This vulnerability can be exploited by a client ... Exploitation of this vulnerability can lead to remote ...
    (Cert)
  • Re: freebsd-security Digest, Vol 482, Issue 1
    ... http://heartbleed.com/ describes an openssl vulnerability published ... FreeBSD 10 and we are also going to need an updated port. ... The implications of this vulnerability are pretty massive, ... unsigned int payload; ...
    (FreeBSD-Security)
  • [CLA-2004:834] Conectiva Security Announcement - openssl
    ... OpenSSL versions distributed with Conectiva Linux: ... vulnerability was discovered by the OpenSSL team using the ... after the new packages are installed. ...
    (Bugtraq)
  • [SECURITY] [DSA 2896-2] openssl security update
    ... This revision to the recent OpenSSL update, DSA-2896-1, checks for some ... In case of doubt a full system restart is recommended. ... A vulnerability has been discovered in OpenSSL's support for the ...
    (Bugtraq)