Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Strange internet activity

  • From: Barry Raveendran Greene
  • Date: Sat Sep 14 17:00:14 2002




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


> -----Original Message-----
> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of
> Arie Vayner
> Sent: Saturday, September 14, 2002 9:22 AM
> To: nanog@merit.edu
> Subject: Strange internet activity
> 
> 
> 
> 
> Hi
> 
> Has anyone noticed any strange internet activity in the past few hours?
> I have noticed lot's of client host generating a massive number of HTTP 
> GET requests to WEB servers (like a single host sending a flood of more 
> than 50 requests)
> 
> The clients seem to be windows boxs...
> 
> Arie
> 
> 




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.