Upgrade mod_ssl

Matt Alexander plug-discuss@lists.plug.phoenix.az.us
Sun, 15 Sep 2002 11:42:23 -0700 (PDT)


Here's the CERT Advisory regarding the recent Apache/mod_ssl worm
currently infecting Linux systems.  Please patch your system or disable
SSL if you don't use it.
~M


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

_______________________________________________
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug