Common Attacks in Apache

Because Apache is complex, coding errors are possible. Fortunately, Apache is mature enough that this is not a frequent occurrence, and occasionally, overlooked errors are found and fixed. This chapter covers some basics of Apache’s vulnerabilities and recent known security problems. (From Hardening Apache by Tony Mobily, Apress, 2004, ISBN: 1590593782.)

apacheBecause of its complexity (and the inherent complexity of Internet technologies), the Apache software provides numerous opportunities for coding errors to be made, and sometimes they are. Fortunately, Apache is mature enough that this is not a frequent occurrence, and occasionally, overlooked errors are found and fixed.

In this chapter, I explain some basic terminology to help you understand Apache’s vulnerabilities. I then show some of the known security problems that have affected Apache over the last 24 months. The goal of these descriptions is not to understand these specific problems, but so you can see what kind of vulnerabilities Apache can have, how to research them, and where you can find and read the advisories (and understand them).

Common Terms

In this section, I will introduce some key words often used in security advisories. These words are often misunderstood by less-experienced system administrators.

Exploits

An exploit is a simple program used to show how to take advantage of a server’s vulnerability. Exploits can be quite dangerous, because they allow less experienced people (sometimes called script kiddies) to use them blindly and break into many servers on the Internet illegally. Many commercial companies do not like exploits at all and would like to make their publication illegal.

However, having an exploit “out in the wild” is also extremely important because:

  • If companies know that an exploit is available, they will be more likely to release a patch to the problem as soon as possible, because their cus tomers are effectively easy targets.

  • Exploits prove that a vulnerability is actually there and needs fixing. Sometimes software vendors are skeptical and deny that a vulnerability actually exists.
  • Exploits are very useful in learning about computer security. They usually explain where the problem came from (that is, which piece of code was buggy in the original piece of software) and show you exactly how to exploit it.

Many different tricks have been used in order to discourage people from misusing exploits: some were intentionally published with errors so that they can only be used by programmers who understand what the code is doing; others were published in a kind of cryptic format, requiring the user to write a small program to decode the source file of the exploit itself, and so on.

Buffer Overflows

Most programs allocate a reasonable amount of memory to the storage of information provided by the user. If a user deliberately tries to use more than the allocated amount of memory, he or she can damage the program, or even execute malicious code. For example, look at the following program (you should be able to understand it even with very little programming experience):

#include <stdio.h>

main(int argc, char **argv){
  /* Was it the right number of parameters? */
  if(argc != 2){ 
    fprintf(stdout,”Usage: %s PARAMETERn”,argv[0]);
    exit(1); 
  }
  /* OK, display the parameter! */
  display_stuff(argv[1]);
}

/* Function called from main(), used to display the parameter */
int display_stuff(char *parameter){

  /* copy_of_parameter is a buffer of 256 bytes */
  char copy_of_parameter[80];

  /* This means copy_of_parameter=parameter */
  /* And yes, this is very insecure */
  strcpy(copy_of_parameter,parameter);
 
  /* Print out the parameter! */ 
  printf(“The parameter was: %sn”,copy_of_parameter);
}

Assuming that you named your file example.c, you can compile it by typing:

[merc@localhost ch_3]$ cc -o example example.c

All the program does is display the parameter that was passed to it:

[merc@localhost ch_3]$ ./example this_is_the_parameter
The parameter was: this_is_the_parameter
[merc@localhost ch_3]$

This program seems fine, but it actually isn’t, because the program assumes that the user won’t pass a parameter longer than 79 characters. So, if the user types the following:

[merc@localhost ch_3]$ ./example 12345678901234567890123456789012345678901234567890
123456789012345678901234567890123 The parameter was: 1234567890123456789012345678901234567890123456789012
3456789012345678901234567890123 Segmentation fault
[merc@localhost ch_3]$

the program crashes (note the “segmentation fault” message). In this program, the problem is in the function show_parameter(), which created a buffer 80 bytes long:

char copy_of_parameter[80];

Then, it copied whatever the user passed as a parameter to the program into that buffer:

/* This means copy_of_parameter=parameter */
strcpy(copy_of_parameter,parameter);

The programmer (wrongly) assumed that nobody would ever run the program passing such a long parameter through the command line. For this reason, the program copied the content of the variable parameter into copy_of_parameter, without checking if parameter would actually fit in it. Many Internet vulnerabilities are based on this problem.

NOTE In some cases, you might have to make the input line a little longer to get the program to crash (in my case, it was 83 characters, only 3 characters longer than allocated).

In the code shown here the user can pass a very long parameter, and therefore overwrite a chunk of memory he or she is not supposed to be able to access. It is possible to organize the extra information so that it rewrites parts of the CPU code the program is made up of, in order to execute an arbitrary piece of assembler code. Doing so requires some knowledge, but it’s not as complicated as it may seem.  

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.

{mospagebreak title=Types of Attacks}

Not every attack is the same. In general, you can divide attacks into two categories:

  • Ones that aim at gaining a remote shell. A remote shell is the ability to run arbitrary commands on a remote computer. For a cracker, having a remote shell is only the beginning; remote shells are usually obtained as a normal user, and in such a situation there is very little a cracker can do. These attacks are generally less common, and are caused by a buffer overflow. They are extremely dangerous, because they give the attacker full access to your server. Even though the attacker is only able to execute commands as the user Apache runs as, very often a remote shell leads to a root shell. A root shell is the ability to run any command as root—in such a case, the user (and the cracker) has complete control over the server.

  • Denial of Service (DOS) attacks. These aim at crashing your server. For example a DOS attack against Apache can be caused by a problem in the way Apache was coded (a weird request could cause Apache to simply die, or consume all the available resources).

Denial Of Service attacks are probably less dangerous than remote shell attacks, but they are much more common and can cause major problems.

Important Reference Sites

There are some key web sites that every system administrator should be aware of when dealing with Apache’s security. For a more comprehensive list of available resources, please refer to Appendix A of this book. Two sites in particular, Apache Week and CVE, are particularly important and are the starting points for the following sections, so I’ll introduce them now.

Apache Week

Apache Week (http://www.apacheweek.com) is a priceless resource for Apache in general; its newsletters will help you keep up with Apache’s development, and you’ll learn important news about Apache. More importantly, its “Apache Security” section is the best summary of the security problems you can find in Apache: http://www.apacheweek.com/features/security-20.

CVE

Every vulnerability is given a very precise name, or ID. For example, the vulnerability “Remote DoS via IPv6” has the ID CAN-2003-0254. The naming convention used is the one set by CVE (Common Vulnerabilities and Exposures). CVE aims to be a dictionary, not a database, of every single publicly known vulnerability. It is also a valuable repository of information on every listed vulnerability. Its web address is http://cve.mitre.org/.   

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.

{mospagebreak title=Apache Vulnerabilities: Practical Examples}

I will now show you three practical examples of vulnerabilities. They are only examples, because new problems are discovered on an ongoing basis. The first two (CAN-2002-0392 and CAN-2001-0925) are dangerous, and can cause unauthorized access to information and remote command execution. The last one, CAN-1999-1199, is a more “classic” DOS attack. For each vulnerability, I will show how I gained information about it, and how I tested it on my own Apache installation (whenever possible).

CAN-2002-0392: Apache Chunked Encoding Vulnerability

This vulnerability is listed on the page http://www.apacheweek.com/
features/security-13
. The same issue is found in the list of Apache 2.0’s problems: http://www.apacheweek.com/features/security-20.

The bug takes advantage of a problem in the way Apache treats chunked transfers. How chunked transfers works is outlined in RFC 2616 (http://www.ietf.org/rfc/rfc2616.txt), which reads:

The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer containing entity-header fields.

Apache fails to calculate the size of the buffer needed to store the chunk’s information. Therefore, a malicious user can make a request that corrupts the server’s memory or crashes the server itself, and in some cases execute arbitrary code on the system.

More information about this vulnerability is available at http://cve.mitre
.org/cgi-bin/cvename.cgi?name=CAN-2002-0392
.

The first line reads:

CONFIRM:http://httpd.apache.org/info/security_bulletin_
20020617.txt

The CONFIRM: field points to a piece of information on the Internet that officially confirms the existence of that vulnerability. In this case, it points to the “Security bulletin” published directly by the Apache Group, where you can read:

While testing for Oracle vulnerabilities, Mark Litchfield discovered a denial of service attack for Apache on Windows. Investigation by the Apache Software Foundation showed that this issue has a wider scope, which on some plat forms results in a denial of service vulnerability, while on some other platforms presents a potential remote exploit vulnerability.

The next point reads like this:

VULNWATCH:20020617 [VulnWatch] Apache httpd: vulnerability with chunked encoding

VulnWatch (http://www.vulnwatch.org) is a web site that aims to be a “nondiscussion, non-patch, all-vulnerability announcement list supported and run by a community of volunteer moderators distributed around the world.” VulnWatch sent a copy of the Apache security bulletin to its subscribers. The archived message can be found at http://archives.neohapsis.com/archives/vulnwatch/2002-q2/0110.html. The string after the colon is the date (20020617), which represents June 17, 2002.

The third line reads:

ISS:20020617 Remote Compromise Vulnerability in Apache HTTP Server

Internet Security Systems (ISS, http://www.iss.net) is a company that provides security products. X-Force is their team of researchers, who keep a database of vulnerabilities compatible with CVE in their naming convention. From the link http://xforce.iss.net/xforce/search.php, you can search their database. For information on this bug, search for 20020617 and read ISS’s own documentation about this security issue.

NOTE Some of the reporting organizations (like ISS) have vested interests in security matters, and some do not publish information until after they’ve made it available to their paying customers. This can potentially create a conflict of interest, and a disservice to the Internet community as a whole.

There are many more entries about this bug on CVE. In particular, the issue was also discussed on BUGTRAQ:

BUGTRAQ:20020619 Remote Apache 1.3.x Exploit

BUGTRAQ is a moderated mailing list focused on computer security. You can see its archive here: http://www.securityfocus.com/archive/1. The exploit was posted on July 19, 2001. You will need to browse the list’s archives to find the message. You may want to test the exploit if you are using BSD and you would like to test your system’s security.

The problem was fixed in Apache 1.3.26 and Apache 2.0.37.

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.

{mospagebreak title=Directory Displayed}

CAN-2001-0925: Requests Can Cause Directory Listing to Be Displayed

This vulnerability is listed at http://www.apacheweek.com/features
/security-13
. Detailed information about this problem is documented here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0925.

Exploiting this problem, an attacker can view the list of files stored in a directory, even if an index.html file is present, if an extraordinary number of slashes (/) are sent to Apache in the requested resource. A request made this way would look like this:

GET ////////////////////////////////////////////// HTTP/1.1

The number of slashes depends on the attacked server.

The attacker can also view the content of any file, if its correct file name is placed where the slashes would have been:

GET ////////////////////////////////////a_file.txt HTTP/1.1

This is an example of a perfectly legal HTTP request that causes problems for Apache (RFC 2396 explains what the syntactic components of a URI are, and of course there is no mention of a limitation on the number of slashes that a URI can have).

The first resource provided by CVE is the Apache announcement:

BUGTRAQ:20010312 FORW: [ANNOUNCE] Apache 1.3.19 Released

It is a link to BUGTRAQ. Using BUGTRAQ’s mail archive at http://www.securityfocus.com/archive/1, you can find the messages posted on March 12, 2001 (from 20010312). Figure 2-1 shows the message: the problem was acknowledged and fixed by the Apache Group. This is enough to prove that a problem actually was there.


Figure 2-1. The message on BUGTRAQ that confirms the problem

  

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.

{mospagebreak title=Common Attacks}

On the third line of the CVE’s description of the bug there is a link to the exploit:

BUGTRAQ:20010624 Fw: Bugtraq ID 2503 : Apache Artificially Long Slash Path Directory Listing Exploit

Again, to find it you should browse BUGTRAQ’s archives. In the message, you can read Mark Watchinski’s explanation of the bug at the beginning of his exploit:

http_request.c has a subroutine called ap_sub_req_lookup_file that in ver y specific cases would feed stat() a filename that was longer than stat() coul d handle. This would result in a condition where stat() would return 0 and a directory index would be returned instead of the default index.html .

stat() is a system call used by Apache to check if a file exists. When stat() returns 0, Apache assumes that the file passed as an argument exists. In this case this assumption is wrong: stat() is only returning 0 because it cannot handle the length of the passed argument. For this to work, the modules mod_dir, mod_autoindex, and mod_negotiation have to be loaded (or present) in the main server, and the accessed directory has to have the options Indexes and Multiviews enabled. The exploit creates a request with a $low number of slashes:

$url = “GET “;
$buffer = “/” x $low . ” HTTP/1.0rn”;
$end = “rnrn”;
$url = $url . $buffer . $end;

This piece of code is repeated a number of times, with the variable $low incremented each time. It then sends the request each time:

print $socket “$url”;

Finally, it checks the result:

while(<$socket>)
  {
    if($_ =~ “Index of”) {

If the result contains “index of,” it means that the targeted server was vulnerable.

NOTE: Your server may use the configuration directives HeaderName and ReadmeName to tailor the server’s output, changing the text “index of,” but nevertheless showing a directory listing because of the vulnerability. So running this against your own server and failing to see “Index of” does not mean you’re not vulnerable; you may have to change the exploit’s code so that it works for your server’s configuration (the exploit will have to look for whatever output is sent by your server for a directory listing, rather than for “Index of”).

Here is a test run of the exploit:

[merc@merc merc]$ ./apache2.pl.txt localhost 80 8092 0
Found the magic number: 4069
Now go do it by hand to see it all
[merc@merc merc]$

If you request a URL like this: http://localhost////////// [... 4069 slashes...] ///, you can get the directory index, and possibly the content of the files in that directory too. Admittedly, typing / 4069 times can be a little tedious, so you could use this instead:

perl -e “print ‘/’ x 4069;”

This short Perl command will print 4069 slashes on screen. You can now use cut-and-paste to copy them into your browser’s address box. Figure 2-2 shows the exploit’s results.

Notice how easy it is to use the exploit even without knowing much about the Web, HTTP, or Apache.

This bug could potentially jeopardize privacy in the server (because an attacker can view any files), as well as security. For instance, an attacker might be able to view your scripts, and therefore know the login and password that the scripts use to connect to the SQL database server.

The solution is simple: Upgrade to a newer version of Apache (at least 1.3.22).


Figure 2-2. The exploit at work

 

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.

{mospagebreak title=SSL Buffer Overflow}

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:

  1. Attacks a web server.

  2. Installs itself using the SSL vulnerability.

  3. 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).

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

[gp-comments width="770" linklove="off" ]
antalya escort bayan antalya escort bayan