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