Common Attacks in Apache - SSL Buffer Overflow (Page 6 of 6 )
CAN-2002-0656: SSL Buffer Overflow Problem (Causes the Apache SSL Worm)
In October 2002 a new Internet worm appeared. The problem now belongs to the past, but when it started, it created a great deal of trouble for many system administrators. I will use this vulnerability as a prime example of an Internet worm.
The worm is based on a vulnerability in OpenSSL, which happens to have four different CVE names (CAN-2002-0655, CAN-2002-0656, CAN-2002-0657, and CAN-2002-0659). This is probably because the OpenSSL Security Advisory (which released information about the problem) highlighted four different vulnerabilities in its advisory. The CVE pages about them, however, are identical.
The Problem
You can find extensive documentation about this issue by going to http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0656.
The problem is in the SSL handshake process: sending a malformed key to the server can cause a buffer overflow, and can allow an attacker to execute arbitrary code on the target machine. The versions of OpenSSL affected are:
- OpenSSL prior to 0.9.6e, up to and including pre-release 0.9.7-beta2
- OpenSSL pre-release 0.9.7-beta2 and prior with Kerberos enabled
- SSLeay library
The first entry in CVE is:
BUGTRAQ:20020730 OpenSSL Security Altert - Remote Buffer Overflows
Browsing BUGTRAQ’s messages, you will find the message (notice that “alert” is misspelled). In the advisory you can read that the problems were found by A. L. Digital Ltd. and The Bunker during a security review in SSL, and that “there are no known exploits for this vulnerability.”
The Bigger Problem
Using the SSL vulnerabilities discussed above, somebody wrote a program that:
- Attacks a web server.
- Installs itself using the SSL vulnerability.
- Becomes part of a peer-to-peer network used to perform DDOS attacks (DDOS means “Distributed Denial of Service,” and is an attack where a multitude of computer systems attack, often unknowingly, a single target).
- Looks for more hosts to attack and does the same thing all over again, spreading itself.
Eventually, a large number of hosts will be infected, hence the name “Apache/mod_ssl Internet worm.” The worm doesn’t install itself; this means that a reboot of the machine will be enough to get rid of the worm, at least temporarily, but not the vulnerability.
The advisory by the CERT about this problem (http://www.cert.org/
advisories/CA-2002-27.html) is particularly enlightening. The advisory says:
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.
The worm’s source code is stored in a file called bugtraq.c. Remember that the advisory refers to a particular version of the worm. Unfortunately, anyone is able to get the source code from the Internet (just search for “bugtraq.c”) and change the program, even drastically. This means that there is no definite way to identify the worm on your system.
The solution is to upgrade the version of SSL in use on your server. If you cannot upgrade your SSL library for some reason, a very temporary solution would be to disable SSL2.
Available Documentation on This Bug
An incredible amount of documentation exists for this bug. Here is a list of interesting sites:
Checkpoints Familiarize yourself with common terms used in computer security: exploit, buffer overflow, DOS attack, root shell attack, root kit, script kiddie, and more.
Know how some representative exploits work, to gain a deeper understanding of the possible threats and their consequences. Check http://httpd.apache.org daily to see if a new version of Apache has been released. If it has, update your server(s). Be familiar with relevant web sites such as Apache Week, CVE, VulnWatch, Security focus, CERT, X-Force ISS, and so on (see Appendix A for a detailed list and web addresses). Subscribe to some of these web sites’ newsletters and mailing lists, and read them daily.
This chapter is from Hardening Apache, by Tony Mobily. (Apress, 2004, ISBN: 1590593782). Check it out at your favorite bookstore today. Buy this book now.
|
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |