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