More detailed info on the Mod-SSL worm..... Summary: A worm based on a buffer overflow vulnerability in the SSLv2 handshake is compromising Linux-based Apache/mod-SSL servers [1, 2]. Web sites running OpenSSL versions 0.9.6d or earlier are strongly encouraged to upgrade to the latest version if possible. SSLv2 has been deprecated in favor of v3 and should be disabled within your Web server architecture. A list of vulnerable Web server applications is provided at the end of this message. As of this writing, no IDS signatures for this exploit are publicly available. Counterpane will update this alert when more information is released. Technical Details: The self-propagating exploit, or worm, begins its work by issuing an invalid HTTP GET request to a remote system accepting connections on TCP/80, the default HTTP port. If the response from the remote server includes the word "Apache," a connection request is sent to the victim machine on TCP/443 (the default SSL port), containing code that triggers the SSLv2 buffer overflow described in the 30 July 2002 OpenSSL security advisory and CERT advisory CA-2002-23 [3, 4, 5]. If the exploit is successful, its source code is copied to the victim, compiled using the open source "gcc" compiler, and executed. (If gcc is not present on the victim system, the malicious code will not be compiled.) In addition, the exploit code contains a distributed denial-of-service mechanism. Victim systems begin generating UDP/2002 traffic back to the attacking system, establishing a DDoS control channel. This backchannel may be used to provide information for co-ordinated attacks on other sites. Preliminary research reveals no mechanism within the currently-circulating worm to issue interactive commands to victim systems, but such a modification is relatively straightforward given the networking code in the exploit. The scanning phase of the exploit may generate an Apache log message of the form: GET /mod_ssl:error:HTTP-request HTTP/1.0 or GET / HTTP/1.1 (there may be variants of the exploit in circulation). If the attack proceeds against a vulnerable Apache/mod-SSL server, it leaves no logfile evidence. Compromised systems can be identified by the presence of the malicious source code in /tmp, ie the existence of the files /tmp/.bugtraq.c and /tmp/.bugtraq, and by the presense of UDP traffic being sent and/or received on port 2002. Machines participating in a DDoS may generate high volumes of traffic over a variety of protocols. If the exploit is launched against a patched Apache/mod-SSL system, the following log messages may be present: [error] SSL handshake failed: HTTP spoken on HTTPS port; trying to send HTML error page [error] OpenSSL: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request [Hint: speaking HTTP to HTTPS port!?] The exact format may vary from system to system, but the error messages are expected to contain the phrase "SSL handshake failed" and a reference to an OpenSSL library error. Again, these messages are generated by the patched OpenSSL code and indicate that the exploit attempt was unsuccessful. Countermeasures: If you use OpenSSL as part of your Web server architecture, be sure that you are running the latest version, 0.9.6g [see 3,5 for lists of vulnerable Web server applications and operating systems and patch information). Be sure to restart your Apache server after patching the OpenSSL libraries. Verify that your Apache/mod-SSL installation is running as a non-privileged user. SSLv2 has been deprecated since at least 1998, based on a variety of design problems and vulnerabilities including potential man in the middle attacks and weak message authentication [6]. Disable SSLv2 support within your Apache/mod-SSL configuration file by setting the following parameters within httpd.conf (the location of this file varies): SSLProtocol all -SSLv2 SSLCipherSuite ALL:!ADH:!NULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:+SSLv3: +TLSv1:-SSLv2:+EXP:+eNULL Remediation: The buffer overflow vulnerability exploited by the Apache/mod-SSL worm provides an attacker with system access at the privilege level of the Apache user. This is typically a non-privileged user account, but may then provide the opportunity for a local exploit to grant the attacker administrative access to the compromised host. Because an attacker may have taken actions outside the scope of the exploit code itself, the most conservative response to a compromised system is to rebuild from the last backup known to be clean. Once the system is restored, install the OpenSSL patches and disable SSLv2. There is, however, no evidence that the current version of the exploit makes any system changes other than installing itself and attacking other Apache servers. Until such evidence exists, a less-conservative approach to system recovery may be acceptable. Remove the files /tmp/.bugtraq and /tmp/.bugtraq.c; kill the "bugtraq" process; patch OpenSSL to version 0.9.6g and restart Apache. Note that as the worm propogates, the likelihood of it creating more malicious changes greatly increases. Completely rebuilding the system, and then immediately patching vulnerable applications, is the only reliable way to repair a compromised device. References: [1] CERT Advisory CA-2002-27 Apache/mod_ssl Worm http://www.cert.org/advisories/CA-2002-27.html [2] OpenSSL Vulnerabilities http://isc.incidents.org/analysis.html?id=167 [3] Counterpane Security Alert: Remote Buffer Overflows in OpenSSL http://www.counterpane.com/alert-v20020731001.html [4] OpenSSL Security Advisory [30 July 2002] http://www.openssl.org/news/secadv_20020730.txt [5] CERT Advisory CA-2002-23 Multiple Vulnerabilities in OpenSSL http://www.cert.org/advisories/CA-2002-23.html [6] Secure Sockets Layer Discussion List FAQ v1.1.1, question 4.11: http://www.faqs.org/faqs/computer-security/ssl-talk-faq Vulnerable Web server distributions (note that while the current exploit only affects Linux-based Apache/mod-SSL, we are including links to all systems known to be vulnerable to the SSLv2 buffer overflow): Apple OS X and higher: http://http://www.info.apple.com/users/security/security_updates.html Debian Linux: http://www.debian.org/security/2002/dsa-136 Gentoo Linux: http://www.kb.cert.org/vuls/id/JSHA-5CSPJ9 EnGarde Linux: http://www.linuxsecurity.com/advisories/other_advisory-1338.html Hewlett-Packard: http://www.kb.cert.org/vuls/id/JSHA-5CSM54 IBM Linux Affinity toolkit: http://www.kb.cert.org/vuls/id/JSHA-5CURJ3 and http://www6.software.ibm.com/dl/aixtbx/aixtbx-p Juniper Networks: http://www.kb.cert.org/vuls/id/JSHA-5D3SLC Mandrake Linux: http://www.mandrakelinux.com/en/security/2002/MDKSA-2002-046.php?dis=8.2 NetBSD: http://www.kb.cert.org/vuls/id/CFCN-5CUS8A OpenLDAP: Compiles with OpenSSL, so rebuild once you've upgraded your OpenSSL installation OpenPKG: http://www.kb.cert.org/vuls/id/JARL-5CJL3H Oracle: http://otn.oracle.com/deploy/security/htdocs/opensslAlert.html Red Hat Linux: http://rhn.redhat.com/errata/RHSA-2002-155.html RSA: http://www.rsasecurity.com/products/bsafe/bulletins/BSAFE_SSL_Products_Security_Bulletin_Aug_8_2002.pdf Sun Cobalt RaQs and QUBE servers: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F46424&zone_32=category%3Asecurity and http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F45509&zone_32=category%3Asecurity Sun Crypto Accelerator 1000 board: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F46605&zone_32=category%3Asecurity SuSE Linux: http://www.suse.com/de/security/2002_027_openssl.html Trustix Secure Linux: http://www.trustix.net/errata/misc/2002/TSL-2002-0063-openssl.asc.txt Counterpane would like to thank Rodney Thayer, Michael Batchelder and Ben Laurie for their assistance in preparing this advisory. Counterpane Internet Security is happy to answer any questions you may have regarding this report, and we thank you for your continued support. Counterpane Customer Service: 1-888-710-8171 DISCLAIMER: The information contained within this Security Alert is provided for informational purposes and without warranty. Counterpane recommends consulting your security policy when responding to this or any security-related event. Counterpane also recommends testing any vendor-recommended countermeasures prior to their deployment in a production environment.
This archive was generated by hypermail 2b30 : Sun Sep 15 2002 - 23:18:19 PDT