Hackers Beware

A pointer is a variable that stores a memory location. When a program jumps to other code to execute, it uses a pointer to remember where it left off. In this case, when a subroutine is called, the program needs to jump and execute the subroutine code. If it did this without using a pointer, it would have no idea where to return after it was done executing the subroutine. The pointer stores the location of where it left off so it can return back to the original program in the correct spot.

Now that you know how a normal stack works, let’s look at what happens when you smash the stack (cause a buffer overflow). When programs don’t check and limit the amount of data copied into a variable’s assigned space, that variable’s space can be overflowed. When that buffer is overflowed, the data placed there goes into the neigh-boring variable’s space and eventually into the pointer space.

To cause code to be executed, an attacker takes advantage of this by precisely tun-ing the amount and content of data necessary to cause the buffer to overflow and the operating system stack to crash. The data that the attacker sends usually consists of machine specific bytecode (low level binary instructions) to execute a command, plus a new address for the return pointer. This address points back into the address space of the stack, causing the program to run the attacker’s instructions when it attempts to return from the subroutine.

A key point to remember is that the attacker’s code will run at whatever privileges the software that is exploited is running at. In most cases, an attacker tries to exploit programs that are running as a privileged account such as root or domain administrator, which means that after he has control, he can do whatever he wants. Figure 7.2 graphically depicts how this occurs.

As you can see, this process is fairly straightforward in theory, but is a little more complicated to run by hand. Unfortunately, there is code, which we will cover in this chapter, that performs buffer overflows for an attacker who does not really understand in detail how they work. The previous example illustrates the more complex buffer overflow attack where an attacker executes code. In the next section, we will examine the second type of buffer overflow attack, Denial of Service.

Types of Buffer Overflow Attacks

By nature of how a buffer overflow attack works, an attacker can compromise a machine in one of two ways: by a denial of service attack or gaining access. The easiest type of buffer overflow attack is to crash the machine or cause a Denial of Service attack. Buffer overflow attacks work by putting too much data onto the memory stack, which causes other information that was on the stack to be overwritten. As you can

imagine, important information like operating system data needs to be stored and accessed from the memory stack to ensure that the system functions properly.

With a buffer overflow attack, if enough information can be overwritten in memory, the system cannot function, and the operating system will crash. As you learned in Chapter 6, “Denial of Service Attacks,” this is one form of Denial of Service attack. To recover from this type of attack, you reboot the system. If this system is a production machine, service is interpreted until the system is rebooted and started up again.

As noted in the previous section, the other type of buffer overflow attack is the execution of code that the attacker chooses to run. Because a buffer overflow attack puts too much data into memory, if the attacker is careful, he can overwrite just enough information on the stack and overwrite the return pointer. By doing this, he can cause the pointer to point to the attacker’s code instead of the actual program, causing the his code to be executed. This code can be anything from printing out the password hashes to creating a new account

Why Are So Many Programs Vulnerable?

As we have already mentioned, the main reason so many programs are vulnerable is due to the lack of error checking. If programmers or developers would take the extra time to build more robust code that includes error checking, there would be fewer buffer overflow exploits.

One of the main reasons that so much code has no error checking is because developers make assumptions. They assume that, under normal operation, the amount of memory they allocate for a variable is sufficient. This may be true, however attackers push the threshold, and when an attacker is testing a program for an exploit, it is no longer being used in normal conditions. Often, programs get released and work perfectly for several years, because everyone uses the programs correctly. Then, someone (an attacker) wakes up and asks the fatal question, “What if I pass the program different types of information?” Or, “What if I pass the program more data than it is expecting?” Because few programs perform proper error checking, as soon as people start asking these questions, programs start crashing left and right.

For example, the Ping program was released and used by a large number of people for over 20 years, and it worked as designed. Then, one day in the early 1990s, someone decided to see what would happen if he sent out ping packets with large amounts of data, and systems of all types from various vendors came crashing down. This attack is known as the ping of death and had a detrimental impact on the Internet.

There are countless examples of programs that have been around for a long time, and attackers still find ways to exploit them via buffer overflows. A program that has been around for a while might be stable from a functionality standpoint, but it does not mean that it is secure. In other cases, attackers target programs as soon as they are released looking for vulnerable code that can be exploited with a buffer overflow attack. This is usually the case with major releases of operating systems or other programs.

To illustrate how buffer overflows work, let’s look at a program that prompts the user for her first name and prints the information for that user on the screen. Because most users do not have long first names, let’s allocate 50 characters for the first name. This is based on the assumption that no one has a first name longer than 50 characters. This assumption might be true, but it us based on an implied level of trust that everyone will use the program in the proper manner. By now, you should realize that this trust is unfounded. Programmers need to realize that making assumptions in programs is very dangerous. To have truly secure programs, developers must explicitly put error checking into their programs. This way, if a malicious user comes along, the developers will be protected

Sample Buffer Overflow

To illustrate the kind of assumptions that programmers make, which create opportunities for buffer overflow attacks, let’s look at a simple example. First, let’s set up a buffer that can contain 256 characters. Then, because we do not perform proper bounds checking, an attacker inserts 512 characters into the 256-character buffer, which overflows the buffer. This is a very simple example of a denial of service buffer overflow attack. The attacker just puts as much data as possible onto the stack with the hope of crashing the machine. Here is the code for this example:

void func(void)

{

int i; char buffer[256]; for(i=0;i<512;i++)

buffer[i]='A';

return;

}

As you can see, the container can only hold 256 characters, yet the code tries to store 512 characters. This results in a buffer overflow.

Protecting Our Sample Application

To avoid this type of problem, we should add bounds checking to the program. A simple example of this is to put a statement that tracks how much data is being written to the buffer, and when it tries to exceed the maximum amount, deny the request. For example, an easy way to fix this problem is to put the proper value in the for loop. Because the counter starts with 0, we would stop when the counter is less than 256, as follows:

void func(void)

{

int i; char buffer[256]; for(i=0;i<256;i++)

buffer[i]='A';

return;

}

A second way to fix the problem is to put explicit error checking in the program. This assumes that the loop does not work properly and that a separate statement is responsible to check for errors:

void func(void)

{

int i; char buffer[256]; for(i=0;i<512;i++)

{

if (i >= 256) then exit(1); buffer[i]='A';

}

return;

}

In this case, we are explicitly checking for the maximum size of the buffer and before it can be exceeded, we stop the program. This is done with the if (i >= 256) then exit(1); statement. The statement says if we have written 256 characters to the buffer variable, stop because it cannot hold any more data

Ten Buffer Overflow Attacks

Now that you have a detailed understanding of how buffer overflow attacks work and the different variations, we will cover ten different buffer overflow exploits. The first five will be covered in detail; the remaining five will be brief overviews because they are relatively new exploits:

•NetMeeting Buffer Overflow

•Outlook Buffer Overflow

•Linuxconf Buffer Overflow

•ToolTalk Buffer Overflow

•IMPAD Buffer Overflow

•AOL Instant Messenger Buffer Overflow

•AOL Instant Messenger BuddyIcon Buffer Overflow

•Windows 2000 ActiveX Control Buffer Overflow

•IIS 4.0/5.0 Phone Book Server Buffer Overflow

•SQL Server 2000 Extended Stored Procedure Buffer Overflow

These exploits are performed on all systems from UNIX to Windows and include several buffer overflows for Windows 2000.

NetMeeting Buffer Overflow

An exploit that causes a buffer overflow, which allows an attacker to execute arbitrary code on a client’s machine. A buffer overflow can cause NetMeeting to stop responding or hang if a malicious web page author links to a specially edited NetMeeting SpeedDial entry.After NetMeeting stops responding, a knowledgeable developer can run arbitrary code in the computer’s memory. The exploit works when an attacker sends a victim a specially crafted SpeedDial link. When the victim clicks on the SpeedDial link to supposedly connect to a remote system, the input that is located in the link causes a buffer overflow attack, which can be used to run arbitrary code on the victim’s system.

Exploit Details:

•Operating System: Microsoft NT and Windows 95

•Protocols/Services: SpeedDial Function

This exploit can affect Microsoft NetMeeting versions 2.0 and 2.1 running on Windows NT 4.0 and versions 1.0, 2.0, and 2.1 running on Windows 95 machines.

Detailed Description

NetMeeting has a feature called SpeedDial, which allows a user to click on it and automatically connect to a remote server. It is equivalent to a shortcut in Windows and works similar to the speed dial feature on a telephone. Unfortunately, SpeedDial utilizes a DLL that can be exploited to cause a buffer overflow and execute arbitrary commands. The SpeedDial shortcut, which can easily be sent to a victim by an attacker via NetMeeting chat or even email, takes advantage of a flaw in one of NetMeeting’s associated DLLs, (MSCONF.DLL in version 4.3.2135). This SpeedDial shortcut exploits the incapability of this DLL to handle more than 256 characters in a destination. By creating a SpeedDial link filled

with more than 256 characters, attackers force their own homegrown code onto other portions of the stack, where it can be executed to load any desired program.

Signature of the Attack

When this exploit is run on an NT box, you receive the Rundll error depicted in Figure 7.3.

Figure 7.3. Error message displayed when the NetMeeting exploit is run against a system.

When you see an error message like the one shown in Figure 7.3, you have probably hit some kind of buffer overflow. The error is somewhat generic looking, but examine the values a little closer. To enable this buffer overflow exploit to happen, a string of 0x80 bytes was sent into Microsoft NetMeeting through the address field of a SpeedDial shortcut. The EIP value happens to be 0x80808080, which means it is a stack overflow! All an attacker needs to do is craft an exploit string to have some extra code inside and tweak four of those 0x80 bytes to point to the exploit string. Note that other types of errors bring up similar dialog boxes, and not all are buffer overflows. In addition, some buffer overflows are easier to exploit than others.

Interestingly enough, most users who work with Windows operating systems see these error messages periodically, so they tend to ignore them when they occur. Users need to be trained that error messages occur for a reason and usually indicate an unusual circumstance. Therefore, when they come across any error messages, users should not ignore the message but notify the help desk.

How to Protect Against It

To patch a machine so that it is not vulnerable to this attack, you must apply the latest patches from Microsoft. Microsoft has issued several

patches that will fix this problem in NetMeeting. Knowledge base article q184346 contains additional details. The article also contains the list of patches and where they can be obtained.

Source Code/Pseudo Code

This section will take you through the assembly source code that is used to run this exploit. From an attackers standpoint, even though it affects the Windows environment, there is no easy-to-use GUI program that exploits this vulnerability. The source code and information used in this section is from the Cult of the Dead Cow at www.cultdeadcow.com.

First, the following code allocates 131070 bytes of memory. EAX gets 131070, and GlobalAlloc is called, indirectly addressed from the jumptable -0x14 bytes from EDI. This stores the memory address in ESI. The type of GlobalAlloc is GMEM_FIXED (0), which results in a memory address being returned rather than an unlocked handle:

Next, an attacker creates an Internet handle with a call to InternetOpenA. In this case, all the parameters to InternetOpenA are zero. The Internet handle is returned in EAX and the attacker immediately sets it up as a parameter to the next function he calls:

The following code makes a call to InternetOpenUrlA (at [EDI-0x08]) invoking the chosen URL. The URL type is unspecified in the code, so the URL can be HTTP, FTP, FILE, GOPHER, or whatever the attacker wants.

The below code uses InternetReadFile (at [EDI-0x04]) to download up to 131070 bytes into the memory buffer (pointer in ESI). Note that EDI was pushed first. EDI is where the attacker is going to store the count of how many bytes are actually read. This is needed to save the file to disk with the right size. Note that there is a limit to the size of the exploit executable the attacker can download.

The following code, calls _lcreat (at [EDI-0x28]) to create a file in which to dump the memory buffer. Looking at the last five characters of the URL chooses the filename. In this case, it’s e.exe. The file is created in the place where the exploit was launched (usually the person’s SpeedDial directory in the case of NetMeeting).

The below code is the actual write to disk and is done with a call to _lwrite (at [EDI-0x24]). The parameter for the number of bytes to write is located at [EDI]. Also, the buffer location and the file handle returned by _lcreat are pushed. But before the attacker calls the function, he saves the handle in EBX, which is not modified by _lwrite.

The attacker then closes the file handle to get things committed. All that is left is to execute the file he downloaded and exit this process:

Finally, the attacker tells WinExec to run the executable! Note in the following code that the first inc edx is to select Show Window mode for the executable. If the attacker wants the executable to run in hidden mode, he should nop that line out, and it will use SW_HIDE instead of SW_SHOWNORMAL as the second parameter to WinExec, where the first parameter is the filename:

This process is complete. ExitProcess cleans up, and the attacker is done exploiting the system, which is shown below.

Additional Information

The following sites contain additional information on the NetMeeting exploit:

•http://www.infoworld.com

•http://www.cultdeadcow.com

•http://www.ntinternals.com

•http://www.microsoft.com

Outlook Buffer Overflow

Exploit Details:

Via the Internet, attackers can send email to an Outlook client and cause arbitrary code to run on the victim’s machine. There is a vulnerability in the way Outlook processes email that allows an attacker to compromise systems that are running the affected versions of the mail client’s software. The attacker sends an email with a malformed header that causes a buffer overflow to occur. The buffer overflow has two variations: crash the victim’s machine or cause arbitrary code to run on the victim’s computer. This provides an easy way for an attacker to plant a backdoor on a machine, without the victim knowing about it.

•Name: Remotely Exploitable Buffer Overflow in Outlook Malformed E-mail MIME Header

•Operating System: Microsoft Outlook versions 97, 98, and 2000. Microsoft Outlook Express versions 4.0, 4.01, 5.0, and 5.01.

•Protocols/Services: SMTP Internet mail.

Protocol Description

Simple Mail Transfer Protocol (SMTP) is the mail protocol that is used to send email across the Internet. When an individual wants to send an email to another person, the email is routed through the Internet using SMTP. Let’s look at an example. If Bob wants to send an email message to Sally, he composes the message and clicks Send. It is forwarded to his mail server, which in turn looks up the MX or mail record for Sally’s mail server. The MX section is part of the DNS record that contains the IP address or hostname for the mail server of a specific domain. After Sally’s mail server does this, it makes a connection to Sally’s mail system on port 25 and transfers the email. When Sally wants to check her mail, she opens her mail client and the mail client connects to the server and